Re: [Hipsec] clarification on HIT Suite IDs

Julien Laganier <> Thu, 25 September 2014 04:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C6B01A19F7 for <>; Wed, 24 Sep 2014 21:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MDEiNe-t515q for <>; Wed, 24 Sep 2014 21:21:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92B6A1A19E2 for <>; Wed, 24 Sep 2014 21:21:35 -0700 (PDT)
Received: by with SMTP id z12so9206621lbi.37 for <>; Wed, 24 Sep 2014 21:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vlt38sbaV92b8/3WoEHLHXobFJseJq28u+g6cklhW50=; b=GCsFyDyi+O3yn+HTLjXFPloyL6ljhoVUZl4JwNADYZmTBqb5g5mJ2pfruQKdtA2cvc UyZYMtMyoAWatX9ozYdfJVwwtEPpESoVyM3UlyaZm6WDmT9psci/biYHFQiud5KwZILy 94ZvKaU1dowKub6xnhi58vHkK1/HimN9cMVe8OZN14Gd8LdkaLoUKeAbWMX9EGb4n5zP pN66DZu3Wtcgkza/K2JkmrYu74GDKyic9KUAyCr7YFLzfnAmd5z8kbVWY7DflFi1tGwT 4Y49X/6o6KJbX2lqtqbe/a8zEgP7iXC067d41O5HVBNlTTUucQJqobqZHv59DEoqlwoD n9Tg==
MIME-Version: 1.0
X-Received: by with SMTP id na2mr9898401lbb.70.1411618893003; Wed, 24 Sep 2014 21:21:33 -0700 (PDT)
Received: by with HTTP; Wed, 24 Sep 2014 21:21:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 24 Sep 2014 21:21:32 -0700
Message-ID: <>
From: Julien Laganier <>
To: Tom Henderson <>
Content-Type: text/plain; charset="UTF-8"
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 04:21:37 -0000

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.