Re: [Hipsec] clarification on HIT Suite IDs

Tom Henderson <tomh@tomh.org> Tue, 23 September 2014 19:55 UTC

Return-Path: <tomh@tomh.org>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC61A882E for <hipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 12:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2n5akYZ7C3W for <hipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 12:55:00 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 2DCA51A1AE1 for <hipsec@ietf.org>; 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) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Sep 2014 19:54:56 -0000
Received: from box528.bluehost.com ([74.220.219.128]) 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; d=tomh.org; 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 [71.231.123.189] (port=45549 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <tomh@tomh.org>) id 1XWWAg-0000yo-4w; Tue, 23 Sep 2014 13:54:46 -0600
Message-ID: <5421D003.5020701@tomh.org>
Date: Tue, 23 Sep 2014 12:54:43 -0700
From: Tom Henderson <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julien Laganier <julien.ietf@gmail.com>
References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <CAE_dhju-kOzE1PzTj_+wLfYS4_8kJhWqrxJ16sMC3W6b+sanxQ@mail.gmail.com> <5421B06F.5010301@tomh.org> <CAE_dhjs3TSrME8UPFAw6y_wTye5YvLNAuQ8_KQ4m0sSokULDDg@mail.gmail.com>
In-Reply-To: <CAE_dhjs3TSrME8UPFAw6y_wTye5YvLNAuQ8_KQ4m0sSokULDDg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org}
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/iN-PydJo82xJMdi31axgtKIqkEs
Cc: HIP <hipsec@ietf.org>, Francis Dupont <fdupont@isc.org>
Subject: Re: [Hipsec] clarification on HIT Suite IDs
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=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 <tomh@tomh.org> 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