Re: [Hipsec] clarification on HIT Suite IDs

Rene Hummen <Rene.Hummen@comsys.rwth-aachen.de> Thu, 25 September 2014 12:24 UTC

Return-Path: <Rene.Hummen@comsys.rwth-aachen.de>
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 42A231A6FC2 for <hipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 05:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.636
X-Spam-Level:
X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 UZWs6eoC2Jfg for <hipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 05:24:35 -0700 (PDT)
Received: from mx-out-2.rwth-aachen.de (mx-out-2.rwth-aachen.de [134.130.5.187]) by ietfa.amsl.com (Postfix) with ESMTP id 344591A1B1C for <hipsec@ietf.org>; Thu, 25 Sep 2014 05:24:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,597,1406584800"; d="p7s'?scan'208";a="262323402"
Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-2.rz.rwth-aachen.de with ESMTP; 25 Sep 2014 14:24:21 +0200
Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id B566613DAC2; Thu, 25 Sep 2014 14:24:20 +0200 (CEST)
Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Thu, 25 Sep 2014 14:24:20 +0200
From: Rene Hummen <Rene.Hummen@comsys.rwth-aachen.de>
To: Julien Laganier <julien.ietf@gmail.com>
Thread-Topic: [Hipsec] clarification on HIT Suite IDs
Thread-Index: AQHP1qPQG8XbqWml2E21zaxD1+8moJwOMwXfgAB5boCAAC+JgIAAINGAgAAE04CAAh/wAIAAhuOA
Date: Thu, 25 Sep 2014 12:24:19 +0000
Message-ID: <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de>
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> <5421D003.5020701@tomh.org> <CAE_dhjsMi+1vKM0U0_veB8+FBLLgKqsxo=Vr_Q-1_4KU4AeWmw@mail.gmail.com>
In-Reply-To: <CAE_dhjsMi+1vKM0U0_veB8+FBLLgKqsxo=Vr_Q-1_4KU4AeWmw@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [37.201.229.13]
Content-Type: multipart/signed; boundary="Apple-Mail=_C32AB034-078E-4EB3-A4B0-FD3330ADB283"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/eJpU7U0JtP1Qmb6itiKqoYJ3K8Y
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: Thu, 25 Sep 2014 12:24:38 -0000

Hi all,

just wondering if the decision was made for us, as RFC5201-bis was approved yesterday:

===

The IESG has approved the following document:
- 'Host Identity Protocol Version 2 (HIPv2)'
 (draft-ietf-hip-rfc5201-bis-19.txt) as Proposed Standard

This document is the product of the Host Identity Protocol Working Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/

===

BR
René


On 25 Sep 2014, at 06:21, Julien Laganier <julien.ietf@gmail.com> wrote:
> Hi Tom,
> 
> Please see inline
> 
> On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson <tomh@tomh.org> 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.
> 
> --julien
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/