Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 12 Jan 2010 12:35:48 -0800

> 2.) We have several hash algos for HITs now and it cannot be assumed
> that every host supports every algo.

<snip>

> HI bindings
> ===================
> A host may now have a number of HIs (several signature
> algorithms). This
> results in the question how to bind these HIs together. Until now we
> have only discussed a DNS-(sec)-based binding but other bindings are
> also possible (certificates, etc). However, the question of
> signature-algo compatibility remains. If the signature
> algorithm of the
> certificate is not understood, the binding is useless. In general, it
> would probably make sense to not use crypto agility as a
> "comfort tool"
> that enables to use of any arbitrary combination of
> algorithms but as a
> tool that enables to increase the security of the system whenever the
> currently used algorithms are threatened. Otherwise we will
> end up with
> hosts that have a large number of HIs and even more HITs.
>

Hmm, I am wondering what are the implications of this on the users and higher layer protocols.  What identifiers are the sockets bound to if the HITs may later change (note:  opportunistic mode has this problem already)?  What name(s) do applications use to refer to the peer host?  This seems to be heading us more towards a cert-based architecture above HIP to manage bindings between the stable names (such as FQDN) and the various HIP names.   Not that I think that such a move is bad, but perhaps we need to be more explicit in sketching out the implications.

- Tom

---

From: Tobias Heer <[email-masked]>
Date: Tue, 12 Jan 2010 22:39:58 +0100

Hi Tom, 

Am 12.01.2010 um 21:35 schrieb Henderson, Thomas R:

> Hmm, I am wondering what are the implications of this on the users and higher layer protocols.  What identifiers are the sockets bound to if the HITs may later change (note:  opportunistic mode has this problem already)?

We had a long discussion in Helsinki about changing HITs during a BEX or during an established HIP association. The general opinion was that this is a) complicated and b) would break application-layer bindings (as you noticed in your question). We discussed two possible solutions in the e-mail you are referring to. Solution 2 (resolver selects algorithms) seemed to be the more practical one. The idea was to only present destination HITs to the application for which the resolver verified that the Initiator can use these (because it supports the HIH used for generating the HIT). That way, the application would open a socket with a proper destination HIT and there would not be a need for changing it on the fly. Of course, the resolver must be supplied with the information which HIH was used for generating a certain HIT. This information could also come from the DNS.

Tobias

> What name(s) do applications use to refer to the peer host?  This seems to be heading us more towards a cert-based architecture above HIP to manage bindings between the stable names (such as FQDN) and the various HIP names.   Not that I think that such a move is bad, but perhaps we need to be more explicit in sketching out the implications.
> 
> - Tom
> 
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 12 Jan 2010 14:40:24 -0800

> -----Original Message-----
> From: Tobias Heer [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2010 1:40 PM
> To: [email-masked] WG
> Cc: Henderson, Thomas R
> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility
>
> >
> > Hmm, I am wondering what are the implications of this on
> the users and higher layer protocols.  What identifiers are
> the sockets bound to if the HITs may later change (note:
> opportunistic mode has this problem already)?
>
> We had a long discussion in Helsinki about changing HITs
> during a BEX or during an established HIP association. The
> general opinion was that this is a) complicated and b) would
> break application-layer bindings (as you noticed in your
> question). We discussed two possible solutions in the e-mail
> you are referring to. Solution 2 (resolver selects
> algorithms) seemed to be the more practical one. The idea was
> to only present destination HITs to the application for which
> the resolver verified that the Initiator can use these
> (because it supports the HIH used for generating the HIT).
> That way, the application would open a socket with a proper
> destination HIT and there would not be a need for changing it
> on the fly. Of course, the resolver must be supplied with the
> information which HIH was used for generating a certain HIT.
> This information could also come from the DNS.

Hi Tobias,
Thanks for the quick reply.  My main point is that we should be
clear about where the architecture is headed.  In this case, the
recommended solution relies on DNS(sec) (and the security of the
client resolver) to manage this situation.  How will it work in
the absence of DNS?  (I recall people going to the mike in
meetings past, pleading that we do not bake in a DNS dependency
to HIP.)

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 15:12:09 -0800

> meetings past, pleading that we do not bake in a DNS dependency

Whatever mechanism you use to get a HIT, you also have to get the HIH.  
If the base information is the HI from which you derive a HIT, there 
must be a list of HIHs (min size = 1) in perfered order to use.

In opertunistic mode I would have to provide a list of HIHs it can 
handle so that R can send a usable R1 to it.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 12 Jan 2010 15:36:21 -0800

> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2010 3:12 PM
> To: Henderson, Thomas R
> Cc: 'Tobias Heer'; [email-masked] WG

An implication seems to be that the fact that a HIT is 128 bits long
is less interesting since you also need the HIH.  Should this
be considered in future ORCHIDs (to somehow encode the HIH within
the 128 bits)?

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 15:57:50 -0800

> be considered in future ORCHIDs (to somehow encode the HIH within

We have beaten this thought around and have no real conclusion.  So far 
we are leaving it out to not shrink the collision space more than it is 
already.

I may still need to include a HIH list in I1, as the HIT it 'discovered' 
might not be what R perfers to use given the HIHs supported by I?  This 
is another area that Tobias, Miika, and I have discussed:

Can I and R use different HIHs for their respective HITs.  Should be 
allowed.

Given an intersection of I(HIH) and R(HIH) does I or R select a common HIH?

Of course so far we only have two HIHs:  SHA1 and SHA2.  I am seeing the 
recommendation of SHA-384 to be used with AES 256 in RFC 4869, but I am 
still plowing through this, and this only impacts the HIP and ESP 
transforms not the has to use on a HI.  Better to leave HIH to SHA1 and 
SHA2 until the completion of the hash competition, IMHO.

---

From: Tobias Heer <[email-masked]>
Date: Wed, 13 Jan 2010 09:46:14 +0100

>> From: Robert Moskowitz [mailto:[email-masked]]
[...]

> be considered in future ORCHIDs (to somehow encode the HIH within

I still think that having a IPv6 compatible HIT is useful because a longer HIT is difficult to use in the stack. For legacy-style applications (which work quite nicely with HIP right now), a larger HIT would lead to another mapping. 
Moreover, the HIH is only needed within HIP (and the resolver). It is not needed by the application and will probably not be exposed to it. In my opinion, we could keep the application interface as it is now, even with the HIH.

Tobias

--

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 13 Jan 2010 01:35:49 -0800

> Moreover, the HIH is only needed within HIP (and the resolver). It is not needed by the application and will probably not be exposed to it. In my opinion, we could keep the application interface as…

I think Tom was thinking about a different context for each HIH.  Or a 
couple bits out of the 128 allocated as the HIH value.

With the first option, I don't think you can back derive the HIH from 
the HIT, so nothing really gained.

With the second option you increase the collision risk.

But others might have a different take on this item...

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 13 Jan 2010 08:45:50 -0800

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Robert Moskowitz
> Sent: Wednesday, January 13, 2010 1:36 AM
> To: Tobias Heer
> Cc: [email-masked] WG
> > I still think that having a IPv6 compatible HIT is useful
> because a longer HIT is difficult to use in the stack. For
> legacy-style applications (which work quite nicely with HIP
> right now), a larger HIT would lead to another mapping.
> > Moreover, the HIH is only needed within HIP (and the
> resolver). It is not needed by the application and will
> probably not be exposed to it. In my opinion, we could keep
> the application interface as it is now, even with the HIH.
> >
> >
>

Yes.

> With the second option you increase the collision risk.

The issue I was thinking about is that if it becomes commonplace to
just use HITs as names in lots of places because it is 128-bits long,
it seems to be odd that you will not be able to know the hash used
to construct the HIT just by inspecting the HIT.  And if the day
comes when a hash is deprecated, how do you know whether the
HIT you have of a peer system should be deprecated?  I suppose that
you can try to run the base exchange with them to learn the HIH.
But it may be that people just start to store the HIH with the HIT
explicitly.

I had a separate question on the list recently about the process
for renewing ORCHID and whether changes need to be made.  I don't
know how /28 was arrived at, and whether e.g. 4 bits of the prefix
space could be reclaimed to encode HIH, or whether more bits are
needed for hash output.

Tom

---

From: Tobias Heer <[email-masked]>
Date: Wed, 13 Jan 2010 20:25:30 +0100

Hello Tom, 

> space could be reclaimed to encode HIH, or whether more bits are

I think one could work with four additional bits. This means that 16 different hash functions could be encoded at the same time.
Of course we have to use crypto agility carefully then (i.e., we only introduce new HIH algorithms when the previous becomes insufficient). With 16 possible hash functions, this should give us plenty of time to completely phase out HIH #0 before #15 becomes insecure. If we look at the life-cycle of popular hash functions (MD5, SHA-1) 16 replacements represent a huge time frame. We could start over with #0 when #15 becomes insecure. 

Tobias

--

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 13 Jan 2010 12:32:39 -0800

On 01/13/2010 11:25 AM, Tobias Heer wrote:
>>>>>> If the base information is the HI from which you derive a
>>>>>>              
>>> HIT, there
>>>        
>>>>> An implication seems to be that the fact that a HIT is 128
>>>>>            
>>> bits long
>>>        

Right now I see two for HIH, though there are 3 for transforms.

For HIH, there is SHA-1 and SHA-2.

But for transforms and KEYMAT according to RFC 4869, we need to add 
SHA-384 for Suite-B.  And considering 4869 is authored  by NSA, I guess 
we will be adding SHA-384.  But I don't see us needing it for HIT 
generation.

And this gets me to a struggle I am having right now that I am getting 
close to posting here about the hash used within BEX operations as 
opposed to the hash used in HIT generation...