Re: sticking with 128-bit HITs (was Re: SHA1 broken? )

Tom,

>>> 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.
>>> 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.
>>
>> I'm happy with that, too.
>
> Can we make it 010, with five bits HA?

Why that way?  Why not five bit prefix and three HA?  IMHO
three bits for the hash algorithm should be enough at this
point of time.  What is your rational for this different
allocation of the bits?  I feel that I am lacking information
here.  From my point of view, 3 bits is more than enough for
the hash algorithm (IMHO 2 bits would do), so I don't see any
reason for making it longer.  Secondly, making the prefix longer
is good from a potential IANA allocation point of view.  Sure,
we could do a still longer prefix, e.g. /13, but that would then
make the hash field considerably shorter and thereby less secure.

In other words, IMHO we should either go with no prefix at all,
and just use 3 bits for the hash algorithm, or then go to some
reasonable long prefix, where 5 bits seems like a good choice
considering various implementation issues and how hard it is likely
to get an IANA allocation.

We can certainly wait with the IANA allocation, but IMHO we should
work towards one.  That is the only way that I see for having
"full" backwards compatibility at the IPv6 API, with channel
bindings.

--Pekka