Re: [Hipsec] clarification on HIT Suite IDs

Rene Hummen <> Thu, 25 September 2014 13:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 99D121A00B2 for <>; Thu, 25 Sep 2014 06:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.636
X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xQffJIcM_EZo for <>; Thu, 25 Sep 2014 06:27:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DEA801A0092 for <>; Thu, 25 Sep 2014 06:27:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,597,1406584800"; d="p7s'?scan'208";a="262334679"
Received: from ([]) by with ESMTP; 25 Sep 2014 15:27:33 +0200
Received: from ( []) by (Postfix) with ESMTP id 1563D13DAC2; Thu, 25 Sep 2014 15:27:33 +0200 (CEST)
Received: from ([fe80::d4e:bb9d:9e0:bfee]) by ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Thu, 25 Sep 2014 15:27:32 +0200
From: Rene Hummen <>
To: Julien Laganier <>
Thread-Topic: [Hipsec] clarification on HIT Suite IDs
Thread-Index: AQHP1qPQG8XbqWml2E21zaxD1+8moJwOMwXfgAB5boCAAC+JgIAAINGAgAAE04CAAh/wAIAAmIoA
Date: Thu, 25 Sep 2014 13:27:31 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_FD590739-F251-43C2-BEAB-091DFB6F21B9"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: HIP <>, Francis Dupont <>
Subject: Re: [Hipsec] clarification on HIT Suite IDs
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Sep 2014 13:27:36 -0000

On 25 Sep 2014, at 06:21, Julien Laganier <> wrote:
> Hi Tom,
> Please see inline
> On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson <> 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.

Separating the OGA ID from the HIT suite ID certainly has its advantages regarding the small OGA ID space. However, it also has implications on HIPv2 crypto-agility. For example, how should the Initiator select the destination HIT if it receives multiple Responder HITs from DNS but only supports ECDSA?

Plus, end-hosts would have to support multiple hash functions to cater to a situation where the HIP hash function does not match the hash function indicated by the OGA ID (which admittedly only is a minor issue for Internet hosts).

So, I propose to _not_ make any major modifications 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

Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426