Re: [Hipsec] clarification on HIT Suite IDs

Tom Henderson <> Tue, 23 September 2014 19:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B3CC61A882E for <>; Tue, 23 Sep 2014 12:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z2n5akYZ7C3W for <>; Tue, 23 Sep 2014 12:55:00 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 2DCA51A1AE1 for <>; Tue, 23 Sep 2014 12:54:59 -0700 (PDT)
Received: (qmail 1092 invoked by uid 0); 23 Sep 2014 19:54:56 -0000
Received: from unknown (HELO CMOut01) ( by with SMTP; 23 Sep 2014 19:54:56 -0000
Received: from ([]) by CMOut01 with id ujul1o00F2molgS01juoF4; Tue, 23 Sep 2014 13:54:55 -0600
X-Authority-Analysis: v=2.1 cv=LbyvtFvi c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=toYhf8nle-0A:10 a=3qaCO0jm4NsA:10 a=q7J0aIbBmN8A:10 a=IkcTkHD0fZMA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=2GSWrlNzA0s2OwzrBm4A:9 a=E1NrTt1BG3J4Is7R:21 a=twbZkROC3I8D6hVc:21 a=QEXdDO2ut3YA:10 a=OuPSdZv8c7MA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bJtgdjuF79nFLCMmFOHsxyYcFQE907QhQzdzLtKwVTc=; b=c1xr0D6ioxIdg9AzfGSFqqYRpflhg7KC2k5tc4yBOTdtsEyLJ75m7dgIBDnnm2jdxtetE8+IOq0wTiqP2DzWRzMftCpd0PhnTcEGVvV2eFonfm20CxtWtzrcYIXn3cSC;
Received: from [] (port=45549 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1XWWAg-0000yo-4w; Tue, 23 Sep 2014 13:54:46 -0600
Message-ID: <>
Date: Tue, 23 Sep 2014 12:54:43 -0700
From: Tom Henderson <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julien Laganier <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
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: Tue, 23 Sep 2014 19:55:01 -0000

Julien, responses inline below.

On 09/23/2014 12:37 PM, Julien Laganier wrote:
> Hi Tom,
> Please see inline.
> On Tue, Sep 23, 2014 at 10:39 AM, Tom Henderson <> wrote:
>> Hi Julien,
>> I agree generally with your recommendations but I have a modified proposal
>> (below):
>> On 09/23/2014 07:49 AM, Julien Laganier wrote:
>> <snip>
>>> The statement about using more bits of the ORCHID to encode a HIT
>>> suite ID seems to be factually incorrect, or at least it isn't
>>> supported by the ORCHIDv2 generation scheme as published in RFC 7343.
>>> Since this document (5201-bis) doesn't seem to be the right place to
>>> specify (future) ORCHID generation (a revision of ORCHIDv2 would), I'd
>>> like to suggest that plans for future enhancements be removed from the
>>> paragraph, and to only keep text necessary to ensure future
>>> enhancements are not prevented. For this, reserving the value zero
>>> seems to be enough. (and Appendix E already has a discussion of OGA ID
>>> reuse for the purpose of ID space exhaustion).
>>> Accordingly, the paragraph would read:
>>>        The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
>>>        opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
>>>        This difference is a measure to accommodate larger HIT Suite IDs if
>>>        the 16 available values prove insufficient.  Hence, the
>>>        current four-bit HIT Suite-IDs only use the four higher order bits
>>> in
>>>        the ID field.  Future documents may define the use of the four
>>> lower-
>>>        order bits in the ID field.
>> What I think is still lacking in the draft is a clear distinction between
>> the OGA ID and the HIT Suite ID, and perhaps some clearer wording that the
>> ID field in the HIT_SUITE_LIST is not yet another parameter needing a
>> registry.
>> HIT Suite IDs are a combination of hash function, HMAC, and signature
>> algorithm(s).  Francis stated that they are an extension of (or derived
>> from) the OGA ID.  The HIT_SUITE_LIST IDs are specific eight-bit encodings
>> of the HIT Suite ID values.
> 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?

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

- Tom