Re: [Hipsec] clarification on HIT Suite IDs

Rene Hummen <> Thu, 25 September 2014 12:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 42A231A6FC2 for <>; Thu, 25 Sep 2014 05:24:38 -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 UZWs6eoC2Jfg for <>; Thu, 25 Sep 2014 05:24:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 344591A1B1C for <>; Thu, 25 Sep 2014 05:24:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,597,1406584800"; d="p7s'?scan'208";a="262323402"
Received: from ([]) by with ESMTP; 25 Sep 2014 14:24:21 +0200
Received: from ( []) by (Postfix) with ESMTP id B566613DAC2; Thu, 25 Sep 2014 14:24:20 +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 14:24:20 +0200
From: Rene Hummen <>
To: Julien Laganier <>
Thread-Topic: [Hipsec] clarification on HIT Suite IDs
Thread-Index: AQHP1qPQG8XbqWml2E21zaxD1+8moJwOMwXfgAB5boCAAC+JgIAAINGAgAAE04CAAh/wAIAAhuOA
Date: Thu, 25 Sep 2014 12:24:19 +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=_C32AB034-078E-4EB3-A4B0-FD3330ADB283"; 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 12:24:38 -0000

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:



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.
>> 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