Re: [Hipsec] clarification on HIT Suite IDs

Tom Henderson <tomh@tomh.org> Tue, 23 September 2014 05:34 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 899C21A1B63 for <hipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 22:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.232
X-Spam-Level:
X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 YIyNeoOYojyF for <hipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 22:34:42 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 8049D1A1AF7 for <hipsec@ietf.org>; Mon, 22 Sep 2014 22:34:42 -0700 (PDT)
Received: (qmail 17731 invoked by uid 0); 23 Sep 2014 05:34:41 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 23 Sep 2014 05:34:41 -0000
Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id ubaa1o00D2molgS01badM3; Tue, 23 Sep 2014 05:34:41 -0600
X-Authority-Analysis: v=2.1 cv=fdw+lSgF 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=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=UVus2lXXwzhgxlCeeGkA:9 a=wPNLvfGTeEIA: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=J5IxGdOVJsEYt5rVPICfYYaAjp5XphOsJ1WPSTQVC1A=; b=aGRHosrTaAU6oXzO5YY8rE5ZPeJpn/mJ7bHhDqctmSh1IoyipCz5pMTtBWpJJ+tGLyVvHwGcw+xZpFbEOOlnWU11Jvlmt0ENx4E96kCjYrDI2wW1/RAdX8gcPZxO1Bi6;
Received: from [71.231.123.189] (port=39901 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 1XWIkE-0002G1-Vo; Mon, 22 Sep 2014 23:34:35 -0600
Message-ID: <54210668.4050605@tomh.org>
Date: Mon, 22 Sep 2014 22:34:32 -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: Francis Dupont <fdupont@isc.org>
References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org>
In-Reply-To: <20140922212826.5048E216C3B@bikeshed.isc.org>
Content-Type: text/plain; charset="ISO-8859-1"; 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/kcam6UQ1bH35Nf_VbdT_NyOdbMs
Cc: HIP <hipsec@ietf.org>, julien.ietf@gmail.com
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 05:34:43 -0000

On 09/22/2014 02:28 PM, Francis Dupont wrote:

>>
>> Basically, the draft is saying that if HIT Suite ID is zero, then this
>> ORCHID encoding:
>>
>>    ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )
>>
>> becomes instead:
>>
>>    ORCHID     :=  Prefix | HIT Suite ID | Encode_92( Hash )
>>
>> and the bits immediately after the Prefix are used also to identify the
>> length of this OGA ID.  It seems to me that this could either be
>> clarified further in the draft, or simplified.
>
> => no, it doesn't say that: the current wording is:
>
>     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.  In that case, one of the
>     16 values, zero, will be used to indicate that four additional bits
>     of the ORCHID will be used to encode the HIT Suite ID.  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.

Perhaps we can agree that it is ambiguous; elsewhere it also states:

       For the time being, the HIT Suite uses only four bits because
       these bits have to be carried in the HIT.  Using more bits for the
       HIT Suite ID reduces the cryptographic strength of the HIT.

which implied to me that the HIT suite ID may in the future consume more 
bits presently allocated to hash.

>
> So there is nothing very clear about what will happen if one will need
> more than 15 HIT Suite-IDs... BTW according to appendix E I should add
> "at the same time" (appendix E proposes to reuse values, making unlikely
> to really need more than 15 values).

I'm not sure where you are proposing to add the clause; can you point 
out the sentence?

>
>> For clarification, it might be a good idea to add some text that says
>> more explicitly that the OGA ID is formed by taking the four high-order
>> bits of the ID found in the HIT_SUITE_LIST, and by making the table read
>> something like:
>
> => it is trade-off between defining OGAs from HIT Suite-IDs vs.
> defining HIT Suite-IDs from OGAs. The second was chosen...
>
>> However, I wonder whether the better choice would be to simplify the
>> current encodings and make it a right-aligned field, keep the value 0 as
>> reserved, and leave future growth to future updates.  The same kind of
>> growth could be accommodated if the (future) extended OGA ID were
>> encoded with the nibbles swapped.
>
> => no, the current choice makes more sense with the HIT Suite-IDs
> from OGAs. But it is a matter of taste for sure...
>

Perhaps we could start by trying to resolve whether the plan should be 
to reuse four-bit values if the space is eventually exceeded, or whether 
the HIT suite ID may grow in the future (and how that affects the 
ORCHID).  Maybe we do not need to specify the plan in this draft; maybe 
we could just avoid the problem for now and just keep value 0 reserved 
and state that what to do when the HIT_SUITE_ID space is exhausted is 
for further study, with deprecated value reuse and expansion of the HIT 
Suite ID being two possibilities.

Another basic question I have is whether the table 11 in Appendix E 
should be merged with the unlabeled table at the end of 5.2.10 (and 
located in 5.2.10), and whether Appendix E text in general ought to be 
brought forward in the draft to section 3.2 and/or 5.2.10.

- Tom