Re: [Hipsec] clarification on HIT Suite IDs

[Rene Hummen <[e-mail]>]

Hi all,

just wondering if the decision was made for us, as RFC5201-bis was approved yesterday:

===

The IESG has approved the following document:
- 'Host Identity Protocol Version 2 (HIPv2)'
 (draft-ietf-hip-rfc5201-bis-19.txt) as Proposed Standard

This document is the product of the Host Identity Protocol Working Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/

===

BR
René


On 25 Sep 2014, at 06:21, Julien Laganier <[e-mail]> wrote:
> Hi Tom,
> 
> Please see inline
> 
> On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson <[e-mail]> wrote:
>> Julien, responses inline below.
>> 
> 
> <cutting thru a bit>
> 
>>> I may be lacking the background behind tying the OGA ID to the HIT
>>> suite ID, but IMHO it makes little sense to tie an identifier for a
>>> combination of hash, HMAC, and signature (the HIT Suite ID), with that
>>> of the identifier for a hash function (the OGA ID), especially when
>>> the ID space for the latter is of such a small size.
>>> 
>>> It implies that if we wanted to create a new HIT suite that just
>>> changes the signature algorithm, because the hash function in use is
>>> still perfectly good, we in effect burn one OGA ID in the small
>>> 15-number space for no extra hash agility w.r.t ORCHID. To me it seems
>>> like a bad thing to do.
>>> 
>>> Why can't the HIP specification  creates a HIP registry for its OGA
>>> ID, and allocate value 1, 2, and 3 to the OGA SHA256, SHA384 and SHA1
>>> on one hand, and on the other hand define a HIP registry for the HIT
>>> suite, and allocate ID 1, 2 and 3 as follows:
>>> 
>>>         HIT Suite
>>>         RESERVED                                            0
>>>         RSA,DSA/SHA-256/OGAID1                  1
>>>         ECDSA/SHA-384/OGAID2                      2
>>>         ECDSA_LOW/SHA-1/OGAID3               3
>>> 
>>> This decouples the burn rate for the HIT suites from that of the OGA
>>> ID (small) space, thus making it possible to define in the future HIT
>>> suite 4 with ECDSA/SHA-512 but still OGAID1....
>> 
>> 
>> IMHO the above is better than what I proposed, if the WG is willing to make
>> this kind of a change at this point.
>> 
>> Perhaps we should ask at this point for other WG opinions on whether the
>> above decoupling is acceptable?
> 
> Yes we should.
> 
> But does silence implies consent? :)
> 
>>>> Accordingly, would you agree to a modification to your proposal, as
>>>> follows?
>>>> 
>>>>      The ID field in the HIT_SUITE_LIST is an eight-bit field that
>>>>      encodes a HIT Suite ID value in its higher-order four bits,
>>>>      leaving the lower-order four bits reserved.  The encoding is
>>>>      a measure to allow for possibly larger HIT Suite IDs in the
>>>>      future, although such expansion is outside the scope of this
>>>>      document.  The lower-order four bits of the ID field are set
>>>>      to zero by the sender and ignored by the receiver.
>>>> 
>>>>      The HIT Suite IDs are an expansion of the OGA IDs that denote
>>>>      which hash function corresponds to a given HIT.  The OGA ID
>>>>      encodes, in four bits, the value of the HIT Suite ID that
>>>>      corresponds to the hash function (and other algorithms) in use.
>>>>      A registry for the OGA ID is not separately established since
>>>>      the values are aligned with those of the HIT Suite ID.
>>>> 
>>>>      The four-bit OGA ID field only permits 15 HIT Suite IDs
>>>>      (the HIT Suite ID with value 0 is reserved) to be used at
>>>>      the same time.  If 15 Suite IDs prove to be insufficient,
>>>>      future documents will specify how additional values can
>>>>      be accommodated.
>>> 
>>> 
>>> If a receiver ignores the low order four bits of the suite ID field,
>>> if in the future we decide to use the remaining low order four bits,
>>> won't they be required to be used with the reserved value zero for the
>>> 4 high order bits?
>>> 
>>> That would limit the HIP Suite ID to a total of 31 legitimate values
>>> instead of the full 255 available. Shouldn't we rather have a receiver
>>> treat the low order bits not set to zero as an error instead?
>> 
>> 
>> I just suggested that handling based on the traditional way of specifying
>> reserved bits (be liberal in what you accept...).  But I agree with you that
>> there is a difference here with respect to the existing non-reserved values,
>> so thank you for catching this.  I propose to amend the above by deleting
>> "and ignored by the receiver".  We could go further by explicitly stating a
>> response if the bits are set, or just leave it as an implicit "Parameter
>> Problem" case just as if a value outside of 1,2 or 3 were received.
> 
> Having the receiver reply with a "parameter problem" when it receives
> a Suite ID value outside of the set of values it understands sounds
> good. For now that is 1, 2, and 3, but can be amended in the future.
> 
> --julien
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/