Re: [Hipsec] Antwort: Re: clarification on HIT Suite IDs

Tom Henderson <tomh@tomh.org> Fri, 10 October 2014 05:13 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 87B061A01A5 for <hipsec@ietfa.amsl.com>; Thu, 9 Oct 2014 22:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 5k9IkuNYnXmd for <hipsec@ietfa.amsl.com>; Thu, 9 Oct 2014 22:13:57 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1EC5A1A0197 for <hipsec@ietf.org>; Thu, 9 Oct 2014 22:13:56 -0700 (PDT)
Received: (qmail 3469 invoked by uid 0); 10 Oct 2014 05:13:56 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Oct 2014 05:13:56 -0000
Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id 1PDn1p00C2molgS01PDqb8; Fri, 10 Oct 2014 05:13:55 -0600
X-Authority-Analysis: v=2.1 cv=EP2VjTpC 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=q7J0aIbBmN8A:10 a=N659UExz7-8A:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=y3McqqjxkrDH_RTRx94A:9 a=pILNOxqGKmIA: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=0pnp8mIQWP+3QnnYUb93Ul/dAqP1jecmhuAnhgOdtp0=; b=BYLjh7Q3We0YbUQMUM6hALgMhkoMDiJTv+65uWMTzGxo2TlVJkyZMEhmb78JCRsca2daG5rFmHZh+H99K4k3PQ+AkRQWBfaLPoQSOvyiKg9EaJ1TCck+J51BVIxRN8id;
Received: from [71.231.123.189] (port=34800 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 1XcSWS-0005dp-1m; Thu, 09 Oct 2014 23:13:48 -0600
Message-ID: <54376B08.90906@tomh.org>
Date: Thu, 09 Oct 2014 22:13:44 -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: Rene Hummen <Rene.Hummen@comsys.rwth-aachen.de>
References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <20140923112746.EA16C216C3B@bikeshed.isc.org> <OFD6408C65.060C7582-ONC1257D62.005816DE-C1257D62.0059BBB9@belden.com> <542991A8.4020908@tomh.org> <CAE_dhjtRkfx+hZ512d1+CMCdpJJx8-ja4nwT=XAi_YC68L4LcA@mail.gmail.com> <543629E6.8030802@tomh.org> <3E6747D3-A24D-42DF-A7DA-3613B7DE90E4@comsys.rwth-aachen.de>
In-Reply-To: <3E6747D3-A24D-42DF-A7DA-3613B7DE90E4@comsys.rwth-aachen.de>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
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/mCOaEKsd-EGfukdi7hGewUM2gB8
Cc: Julien Laganier <julien.ietf@gmail.com>, Francis Dupont <fdupont@isc.org>, HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] Antwort: Re: 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: Fri, 10 Oct 2014 05:13:59 -0000

On 10/09/2014 09:55 AM, Rene Hummen wrote:
> Hi Tom,
>
> I am not sure if we there was an answer to this question before. Why
> don’t we simply use the four lower-order bits in the HIT_SUITE_LIST
> ID field to convey the HIT Suites ID? That would definitely make the
> mapping between HIT Suites IDs and OGA IDs much clearer as the 4-bit
> and the 8-bit values would be the same. Moreover, I thought we would
> skip the part about using larger HIT suite IDs _in the main protocol
> specification_. I like your added text in the IANA consideration
> though.

I agree with your comment that alignment with lower-order bits in the 
8-bit fields would be clearer.  However, I suppose it was done the way 
it currently reads to facilitate the expansion; I don't remember the 
history of that particular design choice.

I also would be fine to delete the text on larger HIT suite IDs in the 
parameter definition, leaving it for the appendix and IANA 
considerations section.

>
> My proposed changes are inline based on your provided diff:
>
> 31	@@ -3099,8 +3099,11 @@ 32	                     host. Each HIT
> Suite ID is one octet long. The four 33
> higher-order bits of the ID field correspond to the 34
> HIT Suite ID in the ORCHID OGA field. The four 35	-
> lower-order bits are reserved and set to 0 and 36	-
> ignored by the receiver. 37	+                    lower-order bits are
> reserved and set to 0 by 38	+                    the sender.  The
> reception of an ID with the 39	+                    four lower-order
> bits not set to 0 should be 40	+                    considered as an
> error that MAY result in a 41	+                    NOTIFICATION of
> type UNSUPPORTED_HIT_SUITE.
>
> I think the “should” should be a “SHOULD”. Combined, with my above
> suggestion, we could rephrase your revised text as follows: “The
> reception of a HIT Suite ID with one of the four higher-order bits
> set to 1 SHOULD be considered as an error. This error MAY trigger a
> NOTIFICATION message of type UNSUPPORTED_HIT_SUITE."

OK with this, if the other change is indeed made.

>
>
> @@ -3115,13 +3118,55 @@ 46	    the ID field.  Future documents may
> define the use of the four lower- 47	    order bits in the ID field.
>
> The above paragraph about extending the HIT Suite ID space from 4 to
> 8 bit could be removed from the main protocol specification. I don’t
> think there is anything weird about an 8-byte HIT Suite ID field
> alignment in the HIT_SUITE_LIST parameter (if we change the HIT Suite
> ID spec from, e.g., 0x10 to 0x01).
>
>
> 49	-   The following HIT Suites ID are defined: 50	+   The following
> HIT Suites ID are defined, and the relationship between 51	+   the
> four-bit ID value used in the OGA ID field, and the eight-bit 52	+
> encoding within the HIT_SUITE_LIST ID field, is clarified: 53	+ 54	+
> HIT Suite       Four-bit ID    Eight-bit encoding 55	+
> RESERVED            0             0x00 56	+        RSA,DSA/SHA-256
> 1             0x10           (REQUIRED) 57	+        ECDSA/SHA-384
> 2             0x20           (RECOMMENDED) 58	+
> ECDSA_LOW/SHA-1     3             0x30           (RECOMMENDED)
>
> This could remain as in -19 because 4-bit and 8-bit values would not
> differ.

Agreed, if that change is made.

>
>
> 100	+   The hash of the responder as defined in the HIT Suite
> determines the 101	+   HMAC to be used for the HMAC parameter.  The
> HMACs currently defined 102	+   here are HMAC-SHA-256 [RFC4868],
> HMAC-SHA-384 [RFC4868], and HMAC- 103	+   SHA-1 [RFC2404].
>
> This appears to be a small editorial mistake: “HMAC parameter” ->
> “HIP_MAC and HIP_MAC_2 parameters”. To be precise, the hash function
> specifies the RHASH, which in turn determines the hash function to be
> used for HMAC. RHASH is also used as the key derivation function.

I can fix this in the next iteration; the above was copied from Appendix 
E of -19.  Thanks for the catch.

- Tom