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

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

=20

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]=20
> Sent: Thursday, March 24, 2005 1:40 AM
> To: [email-masked]
> Cc: Petri Jokela; Henderson, Thomas R; Pekka Nikander; Tim Shepard
> Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20
> SHA1 broken? )
>=20
> On Thursday 24 March 2005 06:35, Petri Jokela wrote:
> > >>   0      5    7                                              127
> > >>   +------+----+------------------------------------------------+
> > >>
> > >>   | Prfx | HA | Hash                                           |
> > >>
> > >>   +------+----+------------------------------------------------+
> > >>
>=20
> (...)
>=20
> > If there are no objections, I will put this kind of a HIT=20
> in the next=20
> > version of the base draft.
>=20
> I'm fine with the new HIT format.
>=20
> > A minor change, proposed earlier by Tom: Shall we replace the name=20
> > "HIT" with "ULID" to make the identifier more generic or stick with=20
> > the "HIT"? I would like to stay with the "HIT" and use the "ULID"
> > in the future versions of HIP.
>=20
> Well, my understanding is that although a HIT is a kind of=20
> ULID, it encompasses a far more broader scope than a typical=20
> ULID. For example it has a channel binding property (w.r.t.=20
> the associated HI), it is mostly derived from a=20
> flat/unstructured bitstring (at least for Type
> 1 HITs, and in the sense that they are not routable).
>=20
> Hence, I would rather suggest that we add some text=20
> explaining that a HIT is a kind of ULID, along with some=20
> other (rather nice) properties.
>=20

I would support having some language about the inherent binding
properties of the HIT (perhaps in section 3.1). =20

Regarding whether we should use HIT vs ULID as the term for the HIP
header, I would support keeping with "HIT" term so long as we keep the
design space a little bit open in the future for non-hash-based HITs
(previous email).

Tom

=20

---

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

>>> A minor change, proposed earlier by Tom: Shall we replace the name
>>> "HIT" with "ULID" to make the identifier more generic or stick with
>> Well, my understanding is that although a HIT is a kind of
>> ULID, it encompasses a far more broader scope than a typical
>> ULID. For example it has a channel binding property (w.r.t.
>> the associated HI), it is mostly derived from a
>> Hence, I would rather suggest that we add some text
>> explaining that a HIT is a kind of ULID, along with some
> properties of the HIT (perhaps in section 3.1).
>

Sounds good to me.  Basically, I would like to keep the WG work
confined within the charter and the 2003 architecture (as defined
in the architecture draft), only doing minor modifications for sake
of added flexibility in the future.

Past track record at the IETF shows that it has been fairly hard
to anticipate when flexibility would be useful and when detrimental.

--Pekka