Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? )

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar 24 20:21:01 2005

=20

> -----Original Message-----
> From: Tim Shepard [mailto:[email-masked]]=20
> Sent: Thursday, March 24, 2005 6:52 AM
> To: Pekka Nikander
> Cc: [email-masked]
> Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20
> SHA1 broken? )=20

<snip>

> > Hence, I would suggest the following:
> >=20
> >    0      5    7                                              127
> >    +------+----+------------------------------------------------+
> >    | Prfx | HA | Hash                                           |
> >    +------+----+------------------------------------------------+
> >=20
> >     Prfx (5 bits) - Fixed prefix, TBD.  All other values reserved.
> >=20
> >          Suggested prefix for testing: 01000
> >=20
> >     HA (3 bits) - Hash algorithm.
> >=20
> >        000 - SHA-1  (as currently defined)
> >              All other values reserved.
> >=20
> >     Hash (120 bits) - Hash (as specified by HA) of the public key.
>=20
> So I think it would be better (yet equivalent in effect for=20
> now) to explain this as the top byte being reserved to=20
> identify the type of HIT (the hash algorithm used to produce=20
> the bottom 120 bits).  Simply:
>=20
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Htype       |                                               |
>    +-+-+-+-+-+-+-+-+                                               +

I would slightly prefer to use Prefix/Htype, if only for keeping the
door open in the future for non-hash identifiers. =20

I'd also like to see that the prefix type defines further the semantics
of the rest of this first byte.  Specifically, if prefix =3D 001, 110, =
or
111, then the HIT may (in some future use) correspond to an IP address,
and there may be no hash algorithm applied.  However, we would not
specify the use of such prefixes in the base spec-- only that they are
reserved.

So maybe, as a slight variant to Pekka's proposal:

    0      3    8                                            127
   +------+----+------------------------------------------------+
   | Prfx | HA | Hash                                           |
   +------+----+------------------------------------------------+

   Prfx (3 bits) - Fixed prefix, TBD.  All other values reserved
        and do not necessarily imply that the subsequent 125 bits
        correspond to Hash Algorithm and Hash subfields.

        Suggested prefix for testing: 010
  =20
   HA (5 bits) - Hash Algorithm.

   00000 - SHA-1  (as currently defined)
           All other values reserved.

   Hash (120 bits) - Hash (as specified by HA) of the public key.

> The IANA considerations would then be (if we want to be able=20
> to pass these across IPv6 interfaces) that each Htype=20
> allocated takes a /8 chunk out of IPv6 address space.
>=20

Do we need IANA to allocate out of the IPv6 space?  These are not IP
addresses.  Or does the fact that we are coding them to distinguish them
from IP addresses make them implicitly IP addresses?  This has always
been murky to me.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 25 02:23:00 2005

>> So I think it would be better (yet equivalent in effect for
>> now) to explain this as the top byte being reserved to
>> identify the type of HIT (the hash algorithm used to produce
>> the bottom 120 bits).
>
> door open in the future for non-hash identifiers.

My base rationale for keeping prefix and hash algorithm separate
are the following:

  1. If we end up with more than 2-3 hash algorithms in use, we
     are likely to end up in an interoperability nightmare.

  2. Having an explicit prefix may make it easier to progress
     into standards track and live peacefully with IPv6 in the
     IPv6 legacy API.

> of the rest of this first byte.  Specifically, if prefix = 001, 110, or

I agree with this approach.  Keep the option open, but not define it 
now.

> So maybe, as a slight variant to Pekka's proposal:

Given the rationale above, I can't see any benefit form having
the hash algorithm field longer than three bits.  In fact, I would
make it only two bits (as it was originally), but four choices
may be too little over time; even if we should aim using only
one or at most 2-3 algorithms at any given time, we may need to
go from one to another.

When 8 choices run out, maybe in 30 years or so, we can bump the
protocol number.

On the other hand, I do see benefit from having a longer prefix,
even if a few bits from the prefix later would end up in being
used for some other purpose.  The benefit is, obviously, the more
potentially more peaceful co-existence with native IPv6.

> from IP addresses make them implicitly IP addresses?  This has always

They are *not* IPv6 addresses, even though we have certainly played
with the ideas of making them (overlay) routable.  However, having
them live with IPv6 addresses at the IPv6 API is likely to be a
benefit.

--Pekka

---

From: [email-masked] (Tim Shepard)
Date: Fri Mar 25 13:02:01 2005

> I agree with this approach.  Keep the option open, but not define it 

That describes the essential bit of what I was trying to get at by
proposing we just have a byte with one or two assigned code points.
In Pekka's original proposal, it looked like he was defining two
knobs, which would allow future settings independently.

So if we say this:

   If the prefix is 01000,
   
   then the next 3 bits are the HA.
   
   If the prefix is something other than 01000, then the syntax and
   semantics of the following bits (however many there may be)
   are to be defined by future documents.

that makes me happy.

But I see no real point in nailing down the boundry between the first
five bits and the last three bits of this first byte when all we're
going to do is assign one or two of the 256 possible values of this
byte for now and hold all of the rest in reserve.  Any implementation
that encounters an unrecognized value in the first byte is not going
to be able to do anything meaningful with it, whether or not we make a
distinction between the first 5 bits and the last 3 bits.  (If I'm
wrong in the last sentence, please enlighten me.)

>      are likely to end up in an interoperability nightmare.

I agree with that, but if we're going to have that problem, your not
going to be able to stop it by bitfield engineering.  (Engineers who
would make that mistake would have no trouble finding the extra bits
on the other side of the artificial boundry between your two fields.)

> When 8 choices run out, maybe in 30 years or so, we can bump the

These HITs may have a life independent of being carried in the header
of any particular protocol.  They may be stored.  So if there's a
protocol number to be bumped, it's going to have to be inside the HIT
itself.

> them live with IPv6 addresses at the IPv6 API is likely to be a

They are certainly not Global Unicast IPv6 addresses.  But are they
any less of an address than some of the other odd things that are
currently allocated out of 0000::/4 and f000::/4 ?  

IMHO it would be reasonable to argue that HITs are as much of an IPv6
address as say a multicast address, a link local unicast address, or a
loopback address (none of which are real addresses).

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 28 14:13:01 2005

>    are to be defined by future documents.

I'm happy with that, too.

> wrong in the last sentence, please enlighten me.)

If you don't know how to verify the crypto binding between a HIT
and a HI, all you loose is channel bindings.  Operationally, you
can still create the HIP connection etc.  Hence, if you know the
first 5 bits and you know that the next 3 bits encode a hash function
that you have no idea about, you can still use the HIT, just with
(much) lower security level.

The second reason for making them separate is to make it easier to
define a new hash algorithm.  That would only require a WG action
while a new code point at the IPv6 address space may require a much
heavier process.

> protocol number to be bumped, it's going to have to be inside the HIT

Hmm.  So we want HITs that are usable over 30 years, once their
channel bindings property has become obsolete?  Maybe, yes, maybe.
But as an alternative we can certainly define another 5-bit prefix,
if needed.

Again, this is all about the right balance.  As of now I think we
don't see what the right balance is.  Maybe someone should collect
all the arguments in a longish e-mail or short draft?  (Don't have
time / wits for it right now.)

> currently allocated out of 0000::/4 and f000::/4 ?

I can't say for f000::/4, but for 0000::/4, yes, some of those
are as little IPv6 addresses as HITs are...

--Pekka