From nobody Mon Sep 1 09:19:29 2014 Return-Path: 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 136F61A02FF; Mon, 1 Sep 2014 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zDzauhhlbzvb; Mon, 1 Sep 2014 09:19:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E18141A02DF; Mon, 1 Sep 2014 09:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140901161910.6514.64362.idtracker@ietfa.amsl.com> Date: Mon, 01 Sep 2014 09:19:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/VIdwW7L7fEhQquZr8TB-j2j1cjU Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 01 Sep 2014 16:19:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Registration Extension Authors : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5203-bis-06.txt Pages : 14 Date : 2014-09-01 Abstract: This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC5203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5203-bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=2322ab9efc=Tobias.Heer@belden.com Tue Sep 2 10:22:49 2014 Return-Path: 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 DB1A41A6F92 for ; Tue, 2 Sep 2014 10:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 bOC8VGQkbIkv for ; Tue, 2 Sep 2014 10:22:45 -0700 (PDT) Received: from mx1.belden.com (mx1.belden.com [12.161.118.90]) by ietfa.amsl.com (Postfix) with ESMTP id B98CD1A068E for ; Tue, 2 Sep 2014 10:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=belden.com; s=beldencom; c=relaxed/simple; q=dns/txt; i=@belden.com; t=1409678564; x=1412270564; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SH2TQo+q6d4kstI9TefPQfEnUKVKIa75V6gNB+oUsCg=; b=gxu2X80g4rKNnBL0BGc0NxgMpMtXiSiYUkuECYXecVmwHXHOuu5sA8P6+o9LXHTH 1tVt48W+vRQErAePrb5DSHyNic6i57SPutPRPhPICLfGcxgAhU+vxXX2hj5gqk4I MNOeXqRYMBJHLe24YrfpHE529ytHVedeDDYzfWzt+Bk=; X-AuditID: 0a01015a-b7f628e000000d19-49-5405fce32d8e Received: from bdcnotes2.belden.com ( [10.1.1.72]) by mx1.belden.com (Service Ready) with SMTP id E5.AD.03353.3ECF5045; Tue, 2 Sep 2014 13:22:44 -0400 (EDT) To: tomh@tomh.org, stephen.farrell@cs.tcd.ie, hipsec@ietf.org MIME-Version: 1.0 X-KeepSent: E663CEC5:35AA808D-C1257D47:005B2906; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Tobias.Heer@Belden.com Message-ID: Date: Tue, 2 Sep 2014 19:22:41 +0200 X-MIMETrack: Serialize by Router on BDCNotes2/BeldenCDT(Release 9.0 HF625|September 19, 2013) at 09/02/2014 01:22:43 PM, Serialize complete at 09/02/2014 01:22:43 PM Content-Type: multipart/alternative; boundary="=_alternative 005F7509C1257D47_=" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsXCxcjoofvkD2uIwaMoi6mLJjNbTN97jd2i 8e4fJgdmj7XdV9k8liz5yeSx55pGAHNUA6NNUmJJWXBmep6+nU1iXl5+SWJJqkJKanGyrZJT ak5Kap6CS2Zxck5iZm5qka5nsL+uhYWppZJCZoqtkpGSQkFOYnJqbmpeia1SYkFBal6Kkh2X AgawASrLzFNIzUvOT8nMS7dVCg1x07VQsnPxDHZOaGXNWH3/BXvBIsOKz93bWRsYJ2l2MXJy SAiYSHy93M4GYYtJXLi3Hsjm4hASmM8osf3dLHaQhIiAo8Tlfe+YQWxeAUGJkzOfsIDYwgJu Ers6e5khmj0lGn42MELYZhIvL18Es9kEZCS2HdzLBNEbJDH7wkewehYBFYmF7ceYQZZJCKxk lGg/MhNsGbNAgMT8jsPsExh5ZyHZNwtJCsLWkTix6hgzhK0tsejKT/YFjCyrGPlyKwz1ksBh qpecn7uJERJbUTsYn7YoHGIU4GBU4uH9w8IaIsSaWFZcmXuIUYKDWUmE1/krUIg3JbGyKrUo P76oNCe1+BBjENCdE5mluJPzgXGfVxJvbGBAJEdJnPfrp5pgIYF0YExnp6YWpBbBDGXi4ARZ yiUlUgyMytSixNKSjHhQ+ogvBiYQqQbG+MthPM93qVrOuvYnfMr3NQaRV3yDfy/63Gc4LaqI Sy4hs1XM8tSfEF7jAnvtn3+6y2qNl7ZcfbLHWXzy7kUxs2QOv/S5++bkMd7uaeJqjxvS5m2q EMrZwv1ni+zU57O413u8jjD9qS9/4o7+Qz5WsT6W/U9X7tPSvMtcdePwAskL2T/WrtpspcRS nJFoqMVcVJwIAAzI9fv7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/jps8gSk-sEyyg25ZmMoocpXpJ_I Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:24:13 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 005F7509C1257D47_= Content-Type: text/plain; charset="US-ASCII" Hello, I am sorry for the late response... >> >>> (3) Continuing to support the 1536 MODP DHE group but not >>> supporting the 2048 equivalent seems a bit odd, as does not having >>> a code point for the 4096 but group. Similarly, making the 1536 bit >>> group the MTI (in 5.2.7) is odd as is the assertion that "web >>> surfing" can use a lower security level. >> >> I am not aware of the criteria that were used for choosing the DHE >> groups. Can someone else comment on this? > > I don't recall offhand, other than that we went through a round of > review with CFRG back in 2012 and we ended up modifying our crypto > selections based on the feedback received. Bob and Tobias have been the > caretakers of the crypto selections in HIPv2 in general, so I defer to > them. Ok, so let's wait to hear from Bob/Tobias on this one. I tried to reconstruct the approach that we took from the mailing list archives. This dates back to 2010 so I don't remember every detail. We use established algorithms that similar protocols used and discussed the choices here on the list. Here is the discussion thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg03327.html There was some counseling from CFRG as well if I am not mistaken. However, if there is the need for a different set of algorithms or if there is consensus that more algorithms are required, there is no reason not to add another one. The sentence with the web-surfing is a carry over from RFC5201. I think we should change it to a more generic statement along the lines of the mailing list post from 2010: Group 10 is meant for devices with low computation capabilities and should be used only if long-term confidentiality is not required. BR, Tobias -- Dr. Tobias Heer | Head of Embedded Software Development - Functions | Hirschmann Automation and Control GmbH Stuttgarter Str. 45-51 | 72654 Neckartenzlingen | Germany Phone: +49 7127 14 - 1280 | Mobile: +49 171 441 49 22 | Fax: +49 7127 14 - 1600 tobias.heer@belden.com | www.beldensolutions.com | www.blog.beldensolutions.com Hirschmann Automation and Control GmbH, Neckartenzlingen Register Court: Stuttgart, Trade Register No.: HRB 225927 VAT No.: DE 814 212 604 Managing Director: Christoph Gusenleitner, Henk Derksen, Wolfgang Schenk, Johannes Pfeffer DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. --=_alternative 005F7509C1257D47_= Content-Type: text/html; charset="US-ASCII" Hello,

I am sorry for the late response...

>>
>>> (3) Continuing to support the 1536 MODP DHE group but not
>>> supporting the 2048 equivalent seems a bit odd, as does not having
>>> a code point for the 4096 but group. Similarly, making the 1536 bit
>>> group the MTI (in 5.2.7) is odd as is the assertion that "web
>>> surfing" can use a lower security level.
>>
>> I am not aware of the criteria that were used for choosing the DHE
>> groups. Can someone else comment on this?
>
> I don't recall offhand, other than that we went through a round of
> review with CFRG back in 2012 and we ended up modifying our crypto
> selections based on the feedback received.  Bob and Tobias have been the
> caretakers of the crypto selections in HIPv2 in general, so I defer to
> them.

Ok, so let's wait to hear from Bob/Tobias on this one.
I tried to reconstruct the approach that we took from the mailing list archives. This dates back to 2010 so I don't remember every detail. We use established algorithms that similar protocols used and discussed the choices here on the list. Here is the discussion thread:

http://www.ietf.org/mail-archive/web/hipsec/current/msg03327.html

There was some counseling from CFRG as well if I am not mistaken. However, if there is the need for a different set of algorithms or if there is consensus that more algorithms are required, there is no reason not to add another one.

The sentence with the web-surfing is a carry over from RFC5201. I think we should change it to a more generic statement along the lines of the mailing list post from 2010:
Group 10 is meant for devices with low computation capabilities and should be used only if long-term
confidentiality is not required.

BR,

Tobias


--
Dr. Tobias Heer | Head of Embedded Software Development - Functions | Hirschmann Automation and Control GmbH
Stuttgarter Str. 45-51 | 72654 Neckartenzlingen | Germany
Phone: +49 7127 14 - 1280 | Mobile: +49 171 441 49 22 | Fax: +49 7127 14 - 1600
tobias.heer@belden.com | www.beldensolutions.com | www.blog.beldensolutions.com

Hirschmann Automation and Control GmbH, Neckartenzlingen
Register Court: Stuttgart, Trade Register No.: HRB 225927
VAT No.: DE 814 212 604
Managing Director: Christoph Gusenleitner, Henk Derksen, Wolfgang Schenk, Johannes Pfeffer


DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.

--=_alternative 005F7509C1257D47_=-- From nobody Wed Sep 3 21:57:07 2014 Return-Path: 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 9CD2D1A0322 for ; Wed, 3 Sep 2014 21:57:04 -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, 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 VZBmteee0KPz for ; Wed, 3 Sep 2014 21:57:03 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 2D0931A030A for ; Wed, 3 Sep 2014 21:57:02 -0700 (PDT) Received: (qmail 8183 invoked by uid 0); 4 Sep 2014 04:57:01 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 4 Sep 2014 04:57:01 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id mswq1o00m2molgS01swtBj; Wed, 03 Sep 2014 22:57:00 -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=53-2lCgHTR4A:10 a=dE5a-coJAxUA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=WDlp8lUfAAAA:8 a=48vgC7mUAAAA:8 a=XIis5B3UILJaaoxktYcA:9 a=wPNLvfGTeEIA:10 a=KieMgrAKCg8A:10 a=-FfqplK4AEMA: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=Ktpbw2GeG3l5SE5fVZrElogW5myGZ+FG5nTODGXbg54=; b=gtmS3dYRCiNfpLvXHSvmkBsMLRBx2cFo2/WqbSKdZ5dHuZYvEanLAZ7NE5xjtntjyVxLxQTRo1GmMZ8CyHUa+tJgz/922bFFY3AdKzJua3u6NHh/y7V3O240ESQ1CxPO; Received: from [71.231.123.189] (port=36574 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPP6J-0005OO-Vw; Wed, 03 Sep 2014 22:56:52 -0600 Message-ID: <5407F111.3050802@tomh.org> Date: Wed, 03 Sep 2014 21:56:49 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tobias.Heer@Belden.com, stephen.farrell@cs.tcd.ie References: In-Reply-To: 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/ot2MqmCe8QbCJAAYWFn47tekSzI Cc: hipsec@ietf.org Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 04:57:04 -0000 On 09/02/2014 10:22 AM, Tobias.Heer@Belden.com wrote: > Hello, > > I am sorry for the late response... > > >> > >>> (3) Continuing to support the 1536 MODP DHE group but not > >>> supporting the 2048 equivalent seems a bit odd, as does not having > >>> a code point for the 4096 but group. Similarly, making the 1536 bit > >>> group the MTI (in 5.2.7) is odd as is the assertion that "web > >>> surfing" can use a lower security level. > >> > >> I am not aware of the criteria that were used for choosing the DHE > >> groups. Can someone else comment on this? > > > > I don't recall offhand, other than that we went through a round of > > review with CFRG back in 2012 and we ended up modifying our crypto > > selections based on the feedback received. Bob and Tobias have been the > > caretakers of the crypto selections in HIPv2 in general, so I defer to > > them. > > Ok, so let's wait to hear from Bob/Tobias on this one. > > I tried to reconstruct the approach that we took from the mailing list > archives. This dates back to 2010 so I don't remember every detail. We > use established algorithms that similar protocols used and discussed the > choices here on the list. Here is the discussion thread: > > http://www.ietf.org/mail-archive/web/hipsec/current/msg03327.html > > There was some counseling from CFRG as well if I am not mistaken. > However, if there is the need for a different set of algorithms or if > there is consensus that more algorithms are required, there is no reason > not to add another one. How could we move this issue forward? Stephen, would you advocate putting in 2048-bit and 4096-bit groups (perhaps with values 11 and 12 respectively)? Or is there not enough support for this proposal? > > The sentence with the web-surfing is a carry over from RFC5201. I think > we should change it to a more generic statement along the lines of the > mailing list post from 2010: > Group 10 is meant for devices with low computation capabilities and > should be used only if long-term > confidentiality is not required. I'll plan to put the above into the next revision, as it seems non-controversial. - Tom From nobody Thu Sep 4 00:48:25 2014 Return-Path: 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 D1E5A1A6F27; Thu, 4 Sep 2014 00:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 URck3ROWV4Vz; Thu, 4 Sep 2014 00:48:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8C1A6F26; Thu, 4 Sep 2014 00:48:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A2866BF17; Thu, 4 Sep 2014 08:48:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV9jP6vdHtTU; Thu, 4 Sep 2014 08:48:19 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.16.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82875BEBE; Thu, 4 Sep 2014 08:48:19 +0100 (IST) Message-ID: <54081943.3040107@cs.tcd.ie> Date: Thu, 04 Sep 2014 08:48:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Tom Henderson , Tobias.Heer@Belden.com References: <5407F111.3050802@tomh.org> In-Reply-To: <5407F111.3050802@tomh.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/ai-XB5Fl9WUlhT8lp6hkjZ6Uoi0 Cc: hipsec@ietf.org, IESG Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:48:24 -0000 Hiya, On 04/09/14 05:56, Tom Henderson wrote: >> > > How could we move this issue forward? Stephen, would you advocate > putting in 2048-bit and 4096-bit groups (perhaps with values 11 and 12 > respectively)? I would advocate putting in the 2048 bit group yes. I figure you probably don't need the 4096 one on the basis that before one would go there you'd want to switch to some form of ECC. So I'd not argue to define a codepoint for the 4096 bit group for now myself, but equally, I'd not argue against doing so. > Or is there not enough support for this proposal? I'm fine that that's a WG chair call. And now that we've discussed the topic, I've cleared that point in any case, moving to a no-objection overall. Thanks for the discussion. Cheers, S. From nobody Thu Sep 4 06:56:34 2014 Return-Path: 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 88A311A02FC for ; Thu, 4 Sep 2014 06:56:30 -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, SPF_PASS=-0.001] autolearn=unavailable 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 DP1PT1oKmPV9 for ; Thu, 4 Sep 2014 06:56:29 -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 BC2FC1A88AD for ; Thu, 4 Sep 2014 06:56:28 -0700 (PDT) Received: (qmail 4329 invoked by uid 0); 4 Sep 2014 13:56:23 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 4 Sep 2014 13:56:23 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id n7w61o00K2molgS017w9q0; Thu, 04 Sep 2014 13:56:21 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN 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=53-2lCgHTR4A:10 a=dE5a-coJAxUA:10 a=q7J0aIbBmN8A:10 a=IkcTkHD0fZMA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=43fVnSn2dgVZ1oMuhYgA:9 a=QEXdDO2ut3YA: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=RU15I7MUrt2t5+9ECvkoeoWs7D+C0WmMWT2+2HgS8n4=; b=imAarTMzRyakzCfvvRJfmzPYOXNwTk7bZhWG5oQadQ4dSagbcQRqCLfSHFckMvF5M6fbIh7uBuIsrnUqCqeYD/la5TPpuh6qUbDkCoZ5/JgJ3MrlCMHRcSt2RwdM7YDr; Received: from [71.231.123.189] (port=37722 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPXWB-0005qT-E8; Thu, 04 Sep 2014 07:56:07 -0600 Message-ID: <54086F74.7040906@tomh.org> Date: Thu, 04 Sep 2014 06:56:04 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Tobias.Heer@Belden.com References: <5407F111.3050802@tomh.org> <54081943.3040107@cs.tcd.ie> In-Reply-To: <54081943.3040107@cs.tcd.ie> 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/MGlJjTvuSGCU_s-zXzf-zwwXi88 Cc: hipsec@ietf.org, IESG Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 13:56:30 -0000 On 09/04/2014 12:48 AM, Stephen Farrell wrote: > > Hiya, > > On 04/09/14 05:56, Tom Henderson wrote: >>> >> >> How could we move this issue forward? Stephen, would you advocate >> putting in 2048-bit and 4096-bit groups (perhaps with values 11 and 12 >> respectively)? > > I would advocate putting in the 2048 bit group yes. I figure > you probably don't need the 4096 one on the basis that before > one would go there you'd want to switch to some form of ECC. > So I'd not argue to define a codepoint for the 4096 bit group > for now myself, but equally, I'd not argue against doing so. I'm fine with that (adding the 2048 bit group). I propose to add it as "value 11" in the list. I'll wait a few days for concurrence or lazy consensus before making the change, however. - Tom From nobody Fri Sep 5 06:34:19 2014 Return-Path: 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 37CFE1A06E8; Fri, 5 Sep 2014 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 b44sdMaTU9XT; Fri, 5 Sep 2014 06:34:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DA31A06C3; Fri, 5 Sep 2014 06:34:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905133416.15023.60994.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 06:34:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/HJlyhoqwV2oBiyUxKwKyZVeACkQ Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5202-bis-07.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 13:34:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) Authors : Petri Jokela Robert Moskowitz Jan Melen Filename : draft-ietf-hip-rfc5202-bis-07.txt Pages : 38 Date : 2014-09-05 Abstract: This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5202-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5202-bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 5 11:26:02 2014 Return-Path: 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 301651A6EF2; Fri, 5 Sep 2014 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 73AbKBuWtAcn; Fri, 5 Sep 2014 11:25:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA31A03F4; Fri, 5 Sep 2014 11:25:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 11:25:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/mRucBpT6fuOwguFOScSmypeJh3U Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-17.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 18:26:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Version 2 (HIPv2) Authors : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-17.txt Pages : 128 Date : 2014-09-05 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5201-bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 5 11:46:17 2014 Return-Path: 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 F20A41A0167 for ; Fri, 5 Sep 2014 11:46:14 -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 mYmXxznmdSJj for ; Fri, 5 Sep 2014 11:46:13 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id CD4E11A014E for ; Fri, 5 Sep 2014 11:46:13 -0700 (PDT) Received: (qmail 29292 invoked by uid 0); 5 Sep 2014 18:46:08 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 5 Sep 2014 18:46:08 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id nclx1o00R2molgS01cm0lE; Fri, 05 Sep 2014 18:46:06 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b 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=ymHSPu_q9dAA:10 a=dcF4-sBx_54A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=XDRR61gRowoenYvcty0A:9 a=bGrNi8xxfrr48eku:21 a=7WDPPBwo-vacfwR7:21 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=ZuLF6a9prgZNL5TQ2co42twyZWzbI+KpnEsMMhyDLPc=; b=FfBZYCMLfcipPnxhxej5eSMQ26zRpxUk+fuNIPDWOmJcwySpxM+JnbJj1NmpKABkzZ1TTuN3EPocyQrU0WjIszZKw079dG+74UTCAIEj+WcTgIsDZQD5A1pEgGNyeVrF; Received: from [71.231.123.189] (port=43890 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPyWE-0007pG-Iq; Fri, 05 Sep 2014 12:45:58 -0600 Message-ID: <540A04E3.2040203@tomh.org> Date: Fri, 05 Sep 2014 11:45:55 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> In-Reply-To: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> 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/ybcA84cO5qIZ2XpPJYGBxWnlMfo Cc: Barry Leiba , Stephen Farrell Subject: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:46:15 -0000 The new RFC5201-bis [1] draft implements the following changes, discussed on the list: o Clarify that receipt of user data in state CLOSING (Table 7) results in transition to I1-SENT o Add academic reference for the first mention of the RSA algorithm o As part of comment resolution on use of NULL encryption, note that use of a NULL HIP CIPHER is only to be used when debugging and testing the HIP protocol. This only pertains to the ENCRYPTED parameter, which is optional; in practice, if encryption is not desired, better to just not encrypt the Host ID. I believe that the open issue on NULL encryption as a MTI (DISCUSS) on RFC5202-bis [2] (also updated today) is closed now, and the following items remain on RFC5201-bis: 1) proposal to address possibility of a plaintext attack: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 I am not sure whether there is support or a concrete text proposal to change this? 2) proposal to add support for 2048-bit DHE (discussed on the list this week) http://trac.tools.ietf.org/wg/hip/trac/ticket/46 The current proposal is to add support for this in the next version, unless further comments are received. 3) update Appendix C example packet http://trac.tools.ietf.org/wg/hip/trac/ticket/50 4) tracking considerations for HIP http://trac.tools.ietf.org/wg/hip/trac/ticket/47 Stephen most recently said: "However, I won't press this if you don't wanna go there now - it'd be a large enough change and would probably take time. I'll clear this one and if the WG want they can decide to pursue that goal." So perhaps this should serve as a last call on this issue--does anyone in the WG want to pursue a change in this area? 5) I just noticed this suggestion from Barry Leiba and will pick this up in version 18:. In the IANA Considerations, similar to what was done for R1_COUNTER, I suggest this: OLD A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. NEW A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. For clarity, we recommend that the name for the value 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)". END - Tom [1] http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-17.txt [2] http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5202-bis-07.txt From nobody Sat Sep 6 00:25:21 2014 Return-Path: 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 42BD61A000C; Sat, 6 Sep 2014 00:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 TPRPa3-ctJmk; Sat, 6 Sep 2014 00:25:18 -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 D8DC71A0009; Sat, 6 Sep 2014 00:25:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,478,1406584800"; d="p7s'?scan'208";a="259635864" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-2.rz.rwth-aachen.de with ESMTP; 06 Sep 2014 09:25:16 +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 D515513DD04; Sat, 6 Sep 2014 09:25:15 +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; Sat, 6 Sep 2014 09:25:15 +0200 From: Rene Hummen To: Tom Henderson Thread-Topic: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions Thread-Index: AQHPxtK67f46IHLvDEaJII9VTXsxoZvwShiAgAAv64CAAGa/AIACt3aA Date: Sat, 6 Sep 2014 07:25:14 +0000 Message-ID: <65D1C430-5F9C-4A7F-A918-8BF4F480B814@comsys.rwth-aachen.de> References: <5407F111.3050802@tomh.org> <54081943.3040107@cs.tcd.ie> <54086F74.7040906@tomh.org> In-Reply-To: <54086F74.7040906@tomh.org> 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.166] Content-Type: multipart/signed; boundary="Apple-Mail=_7F02C25F-2FE8-401D-8936-B21C0970B440"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/vNJGziMM944-DLQcsWjKpyQNDlE Cc: HIP , IESG , Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:25:20 -0000 --Apple-Mail=_7F02C25F-2FE8-401D-8936-B21C0970B440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 04 Sep 2014, at 15:56, Tom Henderson wrote: > On 09/04/2014 12:48 AM, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> On 04/09/14 05:56, Tom Henderson wrote: >>>>=20 >>>=20 >>> How could we move this issue forward? Stephen, would you advocate >>> putting in 2048-bit and 4096-bit groups (perhaps with values 11 and = 12 >>> respectively)? >>=20 >> I would advocate putting in the 2048 bit group yes. I figure >> you probably don't need the 4096 one on the basis that before >> one would go there you'd want to switch to some form of ECC. >> So I'd not argue to define a codepoint for the 4096 bit group >> for now myself, but equally, I'd not argue against doing so. >=20 > I'm fine with that (adding the 2048 bit group). I propose to add it = as "value 11" in the list. I'll wait a few days for concurrence or lazy = consensus before making the change, however. +1 Ren=E9 -- 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/ --Apple-Mail=_7F02C25F-2FE8-401D-8936-B21C0970B440 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDYwNzI1MTNaMCMGCSqGSIb3DQEJBDEWBBTKR7F23FKZ qF/lPNSBJMLLFNSx/jB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQAiYYTM1MJb LVdJUQQ3+hpWcRxGi3YOaUjDXNES3KlgMadS1D4SaIzb9kn7POvDpuC49igL7ZPbOv5bgH9134Px LOAP6+qCfnAr1eKMd7GhjVBAC3klyJyXyj/kQYraSNfamZIYGuGEbjB2/WBsDVHTXt1ROo4MnPFs a9fI024Kr+h5K5JXVfNFjtG81DKx0v483vS7oq2FCNzR5MPvi+Zifc0yxYQY+1NseIpOw8OBtA+b k7H5Mc/vjJ9Uw+TnpzBMpIAWAi4P+txLxPLrgULloscr5W1wYPWGkpZfmwhInnOledTfoaeP1i0a LOKivLVodHVPIZ2jxZnookh+qW+6AAAAAAAA --Apple-Mail=_7F02C25F-2FE8-401D-8936-B21C0970B440-- From nobody Sat Sep 6 08:25:54 2014 Return-Path: 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 10BBC1A0450 for ; Sat, 6 Sep 2014 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 afxbTx5hCf2A for ; Sat, 6 Sep 2014 08:25:53 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F94F1A0417 for ; Sat, 6 Sep 2014 08:25:53 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 000A31B85D5 for ; Sat, 6 Sep 2014 08:25:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BEB1253E074; Sat, 6 Sep 2014 08:25:52 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 6 Sep 2014 08:25:52 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <540A04E3.2040203@tomh.org> Date: Sat, 6 Sep 2014 11:25:42 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> To: Tom Henderson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/wp4tUv8jGbOw7PV7KLig_lSfLxo Cc: HIP , Barry Leiba , Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 15:25:54 -0000 It looks like the latest rev of 5201-bis does not address the gen-art = review comments nor Francis Dupont's comments, and I haven't seen any = follow-up discussion on Francis' comments. What do the authors believe = the status of these two comment threads is? From nobody Sat Sep 6 08:37:34 2014 Return-Path: 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 D8C271A0466 for ; Sat, 6 Sep 2014 08:37:32 -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, 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 MIBeadBOb41e for ; Sat, 6 Sep 2014 08:37:31 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id D5FB31A045D for ; Sat, 6 Sep 2014 08:37:31 -0700 (PDT) Received: (qmail 21922 invoked by uid 0); 6 Sep 2014 15:37:30 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 6 Sep 2014 15:37:30 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id nxdL1o0052molgS01xdPfx; Sat, 06 Sep 2014 15:37:29 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b 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=eJebKyjBspgA:10 a=AGHQCz_AdLoA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=Bo2SRHC5O18uxlBIJbwA:9 a=wPNLvfGTeEIA:10 a=ShTCMQEWBIUA: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=UDgswb4zbxmxgXRhsTF04+HE4VBdLzdJYcQX84F4yGE=; b=r6j6GJM+fRu770/4Bf/S5itFIy+g9cYN8nPo5QbQ8ItVVNM6EYYy7wEdmT9LAgi8XaAl5eUhvMj/JLEtQA5gcFLQn2/OiLy8K/NRvxwXZWfSDSkfRk09V+r6FsUx/Vvz; Received: from [71.231.123.189] (port=47672 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XQI3F-0001pE-9y; Sat, 06 Sep 2014 09:37:21 -0600 Message-ID: <540B2A2E.9040905@tomh.org> Date: Sat, 06 Sep 2014 08:37:18 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> In-Reply-To: <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> 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/zY7qhM1F57MMHwtJxBVa68Gf61w Cc: HIP , Tom Taylor , Barry Leiba , Francis.Dupont@enst-bretagne.fr, Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 15:37:33 -0000 On 09/06/2014 08:25 AM, Ted Lemon wrote: > It looks like the latest rev of 5201-bis does not address the gen-art > review comments nor Francis Dupont's comments, and I haven't seen any > follow-up discussion on Francis' comments. What do the authors > believe the status of these two comment threads is? > Ted, I believe that there is only one open issue left from the Gen-Art review, regarding possible plaintext attacks: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 The list discussion on this issue leans against making any change; see the last message of this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html I think I previously handled all of the other comments; if I missed any, please point them out. I have tried to contact Francis a couple of times regarding clarification of his comments and have not seen a reply. This is tracked in issue: http://trac.tools.ietf.org/wg/hip/trac/ticket/49 I'm cc'ing both Tom Taylor and Francis for any further clarifications. - Tom From nobody Sun Sep 7 04:17:04 2014 Return-Path: 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 29E461A01F7 for ; Sun, 7 Sep 2014 04:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 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, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 wl2UcY3-O2Ym for ; Sun, 7 Sep 2014 04:17:01 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093181A01F1 for ; Sun, 7 Sep 2014 04:17:00 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id a13so1437936igq.7 for ; Sun, 07 Sep 2014 04:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tUakFvUpZdQdLoTxrGCQkqRJ9/Ug8W/HrhSUL2LGASs=; b=YZkhmOKKxu2Yl6p7CwRGDC2XDDawMvY/sjMNRPmPweNHEYvi1M87SHMPqKA50EH36O AXI9aPwDWzHwYrxBUmInQz/ildJtpFZtYiNDct2BTGruGCGYmIQk9KBgH5waffoI6HNM w5Ac9okJBCWsjNtEJc8GN3GstUgM0EHBNSjRuqqc4BTkV4t0ZIRZ/MYb85ZnfzZVk6XB 1kDcxizKl2OENqe5VJOkJ+YVrfmCH8NUCMka/SAzg50NXTV1v5MRRjS9hERjzH1AWryy /qFlJxHayWbhJC88WNq2FhtiXyTGJJve9QUlXcLgs9gNE21i0up7zuMl1rm+xS3QIyTo 4Q+Q== X-Received: by 10.43.94.73 with SMTP id bx9mr24776400icc.19.1410088620277; Sun, 07 Sep 2014 04:17:00 -0700 (PDT) Received: from [192.168.97.5] ([67.210.160.130]) by mx.google.com with ESMTPSA id mj4sm6258722igb.2.2014.09.07.04.16.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 04:16:59 -0700 (PDT) Message-ID: <540C3EB0.2000004@gmail.com> Date: Sun, 07 Sep 2014 07:17:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , Ted Lemon References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> In-Reply-To: <540B2A2E.9040905@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/9TaiKu8RmCbiEXGxGDVEhMabynA Cc: HIP , Barry Leiba , Francis.Dupont@enst-bretagne.fr, Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 11:17:02 -0000 I'm happy with the outcome. The list discussion addressed the issue. I believe the outcome is: "The plaintext attack is resistible, not a real problem, and need not be addressed in the document." Tom Taylor On 06/09/2014 11:37 AM, Tom Henderson wrote: > On 09/06/2014 08:25 AM, Ted Lemon wrote: >> It looks like the latest rev of 5201-bis does not address the gen-art >> review comments nor Francis Dupont's comments, and I haven't seen any >> follow-up discussion on Francis' comments. What do the authors >> believe the status of these two comment threads is? >> > > Ted, > > I believe that there is only one open issue left from the Gen-Art > review, regarding possible plaintext attacks: > > http://trac.tools.ietf.org/wg/hip/trac/ticket/42 > > The list discussion on this issue leans against making any change; see > the last message of this thread: > http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html > > I think I previously handled all of the other comments; if I missed any, > please point them out. > > I have tried to contact Francis a couple of times regarding > clarification of his comments and have not seen a reply. This is > tracked in issue: > > http://trac.tools.ietf.org/wg/hip/trac/ticket/49 > > I'm cc'ing both Tom Taylor and Francis for any further clarifications. > > - Tom > > From nobody Mon Sep 15 04:37:55 2014 Return-Path: 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 71CE11A0B14 for ; Mon, 15 Sep 2014 04:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 iHR9U9yGhbkV for ; Mon, 15 Sep 2014 04:37:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F6D1A068E for ; Mon, 15 Sep 2014 04:37:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-ed-5416cf8ee105 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.30.02247.E8FC6145; Mon, 15 Sep 2014 13:37:50 +0200 (CEST) Received: from [131.160.36.95] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 13:37:49 +0200 Message-ID: <5416CF8D.1070707@ericsson.com> Date: Mon, 15 Sep 2014 14:37:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Tom Henderson References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> <540C3EB0.2000004@gmail.com> In-Reply-To: <540C3EB0.2000004@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7febEQgz/9ahaHFl9itZjZ84/R 4tDLP8wWUxdNZraYvvcau8XW7liLC+t/sVg03v3D5MDh0bKql9ljbfdVNo9Vr9rZPHbOusvu sWTJTyaPmce/sHi8PjCf1WPPNY0Ajigum5TUnMyy1CJ9uwSujKNL1rAVLOSreLvrIVsD4yHu LkZODgkBE4lZm1exQ9hiEhfurWfrYuTiEBI4yijxYecpdghnNaNEz4pvbCBVvALaEjP+vgCz WQRUJeY/Xc4IYrMJWEhsuXWfBcQWFYiSeLXiBitEvaDEyZlPwOIiAooSlw71sYIMZRbYwiTx eM5DsEHCQM3b911ihNh2nFHiy8uvYFM5BTQlmmf1MXUxcgDdJy7R0xgEEmYW0JOYcrWFEcKW l9j+dg4ziC0EdNzyZy0sExiFZiHZPQtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWl lmxiBMbPwS2/rXYwHnzueIhRgINRiYd3wQ6xECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwJj8+1/BzPWa/ZYbeqZF9rw6l7rqe8+BXklmRwu3Q1f+GrHf UWcUvdq3Je6lZpvzTLelV2Rj3NUcl39k+F/j9NV+0sFaJ8/DtnH5po+vBMSuKxLx4v41K1nF WW/izK+a1qtU2D17rpldv9S2df2iy5cyhW452HBbix+7t0PphZ3R06Nrq6bsTVViKc5INNRi LipOBAAzoxLpgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/zzNpFBdmhxJzMhJl9j4J-E_zX_M Cc: Brian Haberman , Jari Arkko , HIP , Francis.Dupont@enst-bretagne.fr, Tom Taylor , Barry Leiba , Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 11:37:54 -0000 Hi Tom (Henderson), Jari, Brian, and Ted still have discusses on this document. Could you please summarize for each of them the status of this draft with respect to their particular comments? Thanks, Gonzalo On 07/09/2014 2:17 PM, Tom Taylor wrote: > I'm happy with the outcome. The list discussion addressed the issue. I > believe the outcome is: "The plaintext attack is resistible, not a real > problem, and need not be addressed in the document." > > Tom Taylor > > On 06/09/2014 11:37 AM, Tom Henderson wrote: >> On 09/06/2014 08:25 AM, Ted Lemon wrote: >>> It looks like the latest rev of 5201-bis does not address the gen-art >>> review comments nor Francis Dupont's comments, and I haven't seen any >>> follow-up discussion on Francis' comments. What do the authors >>> believe the status of these two comment threads is? >>> >> >> Ted, >> >> I believe that there is only one open issue left from the Gen-Art >> review, regarding possible plaintext attacks: >> >> http://trac.tools.ietf.org/wg/hip/trac/ticket/42 >> >> The list discussion on this issue leans against making any change; see >> the last message of this thread: >> http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html >> >> I think I previously handled all of the other comments; if I missed any, >> please point them out. >> >> I have tried to contact Francis a couple of times regarding >> clarification of his comments and have not seen a reply. This is >> tracked in issue: >> >> http://trac.tools.ietf.org/wg/hip/trac/ticket/49 >> >> I'm cc'ing both Tom Taylor and Francis for any further clarifications. >> >> - Tom >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Sep 15 22:20:50 2014 Return-Path: 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 BA78F1A02D4 for ; Mon, 15 Sep 2014 22:20:46 -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, 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 LQmAYD0wWpG0 for ; Mon, 15 Sep 2014 22:20:45 -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 9EFA71A02C1 for ; Mon, 15 Sep 2014 22:20:45 -0700 (PDT) Received: (qmail 14561 invoked by uid 0); 16 Sep 2014 05:20:45 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 16 Sep 2014 05:20:45 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id rhLc1o00Z2molgS01hLflR; Mon, 15 Sep 2014 23:20:43 -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=eJebKyjBspgA:10 a=AGHQCz_AdLoA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=nW_ckIbMICANdN_qIC4A:9 a=wPNLvfGTeEIA:10 a=sr1zk7XcdwYA: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=9YEBECbD9749VhAfWDkhMzvO0AbzKJBcS4iEP4o+dx0=; b=OLnzvIYADMWoXkmoCCln1ZhIZpALVck+gPQqh8Oyl5B0ys9qZXrl6+5i++kLfHca4C2BbhkOvoy5wMrpzPC6y7+fYzA/CNISB0L68o6Ll5nFqq8lYY1EDhZvGIuYm7p2; Received: from [71.231.123.189] (port=44236 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTlBt-0005Yq-QI; Mon, 15 Sep 2014 23:20:37 -0600 Message-ID: <5417C8A2.9070800@tomh.org> Date: Mon, 15 Sep 2014 22:20:34 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gonzalo Camarillo References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> <540C3EB0.2000004@gmail.com> <5416CF8D.1070707@ericsson.com> In-Reply-To: <5416CF8D.1070707@ericsson.com> 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/tawMCBcXaUV0o9NplJGUYDUJ6WQ Cc: Brian Haberman , Jari Arkko , HIP , Francis.Dupont@enst-bretagne.fr, Tom Taylor , Barry Leiba , Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:20:46 -0000 On 09/15/2014 04:37 AM, Gonzalo Camarillo wrote: > Hi Tom (Henderson), > > Jari, Brian, and Ted still have discusses on this document. Could you > please summarize for each of them the status of this draft with respect > to their particular comments? > > Thanks, > > Gonzalo > > Gonzalo, the most recent status on this draft was posted to the HIP list in this message: http://www.ietf.org/mail-archive/web/hipsec/current/msg03942.html Since then, it seems that Jari and Brian have cleared their discusses. I believe that the IANA issues have been mostly resolved (Ted's discuss). Ted's discuss was against version -14 of the draft, while we are at version -17 now. There is a lingering comment that I haven't picked up from Barry (item 5 in the above email) that pertains to IANA text; I plan to publish those in version -18. I could probably put out a version -18 shortly that may resolve all of the open issues, but it just requires that I generate a new Appendix C example packet. I'll try to get to that in the next day or two. - Tom From nobody Fri Sep 19 12:18:39 2014 Return-Path: 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 877FE1A8756; Fri, 19 Sep 2014 12:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 j6ME_9-VP0te; Fri, 19 Sep 2014 12:18:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 214611A04B0; Fri, 19 Sep 2014 12:18:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 714EA18253F; Fri, 19 Sep 2014 12:17:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140919191740.714EA18253F@rfc-editor.org> Date: Fri, 19 Sep 2014 12:17:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/jokjEPnuhPLC5OFr6mfcjrXjhWo Cc: drafts-update-ref@iana.org, hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 7343 on An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:18:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7343 Title: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) Author: J. Laganier, F. Dupont Status: Standards Track Stream: IETF Date: September 2014 Mailbox: julien.ietf@gmail.com, fdupont@isc.org Pages: 14 Characters: 28699 Obsoletes: RFC 4843 I-D Tag: draft-ietf-hip-rfc4843-bis-08.txt URL: https://www.rfc-editor.org/rfc/rfc7343.txt This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. This document is a product of the Host Identity Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Sep 20 01:36:36 2014 Return-Path: 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 A15871A6EEC for ; Mon, 15 Sep 2014 05:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jYnZ9edpdv1N for ; Mon, 15 Sep 2014 05:15:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5191A6EE9 for ; Mon, 15 Sep 2014 05:15:31 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-fa-5416d8613873 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.86.21334.168D6145; Mon, 15 Sep 2014 14:15:29 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 14:15:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A2D441102A6; Mon, 15 Sep 2014 15:15:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9E7D94E98A; Mon, 15 Sep 2014 15:16:53 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C394A4E947; Mon, 15 Sep 2014 15:16:52 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_55D6596B-5C44-42B2-8EB9-D563CB55D4B9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <5416CF8D.1070707@ericsson.com> Date: Mon, 15 Sep 2014 15:15:26 +0300 Message-ID: <378ABA05-5E61-40C2-A105-C8A967EE03CB@ericsson.com> References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> <540C3EB0.2000004@gmail.com> <5416CF8D.1070707@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM+JvjW7iDbEQgwOf5S0OLb7EajGz5x+j xaGXf5gtpi6azGwxfe81dout3bEWF9b/YrFovPuHyYHDo2VVL7PH2u6rbB6rXrWzeeycdZfd Y8mSn0weM49/YfF4fWA+q8eeaxoBHFFcNimpOZllqUX6dglcGUc2drMVnHOsuNv8i7WB8aFN FyMnh4SAiUT7p/WsELaYxIV769m6GLk4hASOMkpcWtfDCuFsYJS4v2s5I4Szl1Fi5v+1TBDO OkaJKTOeQJXNY5T4232XBcRhFpjCKHHkwS0mkMm8AgYSx7//ZAGxhQUsJLbvu8QIYrMJaEls XL6ADcTmFNCRmNd/C8xmEVCVeH2mkwli0GomiaV7Z0ENspdYencj1LrnjBLT5pxnBkmICJhJ LG5bwwTxh7zEhw/H2SFsNYmr5zaB1QgJqEjc+nuWbQKjyCxkF85CciGIzSygLbFs4WtmCNtA 4mnnK1YI21Ti9dGPjBC2tcSMXwfZIGxFiSndD9kXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PL Sy3ZxAiM7YNbfuvuYFz92vEQowAHoxIP74IdYiFCrIllxZW5hxilOViUxHkXnZsXLCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoHR90G2dbl32SyugkOq3yWmCjKfu+tm9vJgSknu37+GbE8m POGP1Y03UDnwoW7Xf2k729leEfte9E38YRWxSSvP7OPpK1uNQtKD5ikZWUdEXP32MvfoPUsR v6KOU1ObFHbzNV27cy9j5cVrgi3zw+fczFzz+TDL3Okvs79e+F84N37ep0QXoUmdSizFGYmG WsxFxYkA4dvjxM4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/KxRh9wGWOcVlhB68Pdl2to9TZnA X-Mailman-Approved-At: Sat, 20 Sep 2014 01:36:35 -0700 Cc: Stephen Farrell , Brian Haberman , HIP , Francis.Dupont@enst-bretagne.fr, Tom Taylor , Barry Leiba Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 12:15:33 -0000 --Apple-Mail=_55D6596B-5C44-42B2-8EB9-D563CB55D4B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tom, Can you respond on the Gen-ART review thread? I=92d love to clear my = discuss, but I have not seen a response yet=85 and it might be that your = newer draft version have already taken all this into account. Jari On 15 Sep 2014, at 14:37, Gonzalo Camarillo = wrote: > Hi Tom (Henderson), >=20 > Jari, Brian, and Ted still have discusses on this document. Could you > please summarize for each of them the status of this draft with = respect > to their particular comments? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/09/2014 2:17 PM, Tom Taylor wrote: >> I'm happy with the outcome. The list discussion addressed the issue. = I >> believe the outcome is: "The plaintext attack is resistible, not a = real >> problem, and need not be addressed in the document." >>=20 >> Tom Taylor >>=20 >> On 06/09/2014 11:37 AM, Tom Henderson wrote: >>> On 09/06/2014 08:25 AM, Ted Lemon wrote: >>>> It looks like the latest rev of 5201-bis does not address the = gen-art >>>> review comments nor Francis Dupont's comments, and I haven't seen = any >>>> follow-up discussion on Francis' comments. What do the authors >>>> believe the status of these two comment threads is? >>>>=20 >>>=20 >>> Ted, >>>=20 >>> I believe that there is only one open issue left from the Gen-Art >>> review, regarding possible plaintext attacks: >>>=20 >>> http://trac.tools.ietf.org/wg/hip/trac/ticket/42 >>>=20 >>> The list discussion on this issue leans against making any change; = see >>> the last message of this thread: >>> http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html >>>=20 >>> I think I previously handled all of the other comments; if I missed = any, >>> please point them out. >>>=20 >>> I have tried to contact Francis a couple of times regarding >>> clarification of his comments and have not seen a reply. This is >>> tracked in issue: >>>=20 >>> http://trac.tools.ietf.org/wg/hip/trac/ticket/49 >>>=20 >>> I'm cc'ing both Tom Taylor and Francis for any further = clarifications. >>>=20 >>> - Tom >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >>=20 >=20 --Apple-Mail=_55D6596B-5C44-42B2-8EB9-D563CB55D4B9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCBEUw ggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVs aWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4X DTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv 1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqT u3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMc CYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUb Az2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2 MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb 8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXI v6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzY FSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67 OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3k MXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OY CMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAw OjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDgg VjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVy YSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5D uVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe 1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF4 6H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGj ggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7ga YqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0F BgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7Bgcq hXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20w cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkww DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUE kUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDC fkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6b KuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHn tP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPd OI5GtDYPMIIEqjCCA5KgAwIBAgIQTyXs3vXto5joAjtwrbnc3jANBgkqhkiG9w0BAQUFADA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMB4X DTEzMDMwNDEzMjUyMVoXDTE2MDMwNDEzMjUxOVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzARBgNV BAMMCkphcmkgQXJra28xEDAOBgNVBAUTB2xtZmphYXIxJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJr a29AZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhwriyJIY5Bbz yZrfnFAjWFLMNc6O6Z6dw5HqexTVyrUymDobuwcFtGl3n+yc6tYcvzM85LJMotJlOJH4NHEqClEc iMw+gFvN17PXxM2aAPuv1ZUL1wSdQ9dS94zxQEQuh4Myyfy+eqvrEBkzZaDPu4Evz6xsmCYPYSZP t4Bo6zbwQqkRvSQUO659ytmlyiPOiWN6wxEpwwO43LEw12xFrVSOQw3AG8ULW/xHbQvInuyWQdBC ug/1n6IJETsMWSrLFnk888IjABXKkmq42EG6RQ0BWLw8lAQwTju7rsDF9HrcTYBcu9z2u/d4cSgH P9SkRncRm68xrt7bD2RhPf3rkQIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZx bGRhcDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFs JTIwQ0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2Uw IgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEw MTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0O BBYEFLk/k+8oySkNxYm0GyPaFaKSRQufMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAECF65IiGH7GS+EEHre+itv2wv0OQ Z68DWR6G9IqMkBgb8dj6JcfFsu+9p8ID1e1L/0ybeTwz1t4IPhuOuWBPohj5irYiCBJkIokUr09B rWPyxfBrSoZ+uXVWfmZSdp15pWlEnHhuGuJkZ2a0MKrj+OEM9qfQR5Cvdlmx5PvsIhFkAFcZWldI xBwHsEeSoGJbVvvNImiY6M27u6rhuR8HanXVdcW4B8gK489LutxKhyhT9QDFUhmyWk2qYCUJgwM/ w44sLz8tv95jDbJxAR/aOwdwF3fQgj8VB5Xwvdn6B0PhfEcd3Ju4yUz6HE6ELZWG4ruE2haUCOn4 8WStKZ/RPDGCApMwggKPAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQTyXs3vXto5joAjtwrbnc3jAJBgUrDgMCGgUAoIIBGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTUxMjE1MjdaMCMG CSqGSIb3DQEJBDEWBBSrcH4T+x5KZEyTfFDMSyZvtriHyTBcBgkrBgEEAYI3EAQxTzBNMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l 7N717aOY6AI7cK253N4wXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l7N717aOY6AI7cK253N4wDQYJ KoZIhvcNAQEBBQAEggEAFSfNQrjR2ezBdl8+uNEaCKQuoi4LoIl0aD66Dh1TBQqi37gI73x3A9b0 KYidmrJOBF9/2S1bn7L3qij+NDKqAbwKilv63PiIbK0x72IEqxs/YpbwiQ5C8spxER6KlgoGx/zG iz/TE5hCrie3EcOoCXSIIrjW9ua3+2Mm1g13Qwcy8iNH4s//8yICxFy7URYPlZEA/D5NsbmCMm7O 0TTC83RuKFm0ExDzCsd3TtxMEg35OplZtKGwLlXApdQ+v4Nw3qpFrPV7kxZ5QSkQskWEM+YuhfB/ +hvIK8qS/hxXCQays9psH8Kd7RdrkwgDGuC04ru3l0NpDs1FiMWBuq8kmwAAAAAAAA== --Apple-Mail=_55D6596B-5C44-42B2-8EB9-D563CB55D4B9-- From nobody Sat Sep 20 01:36:38 2014 Return-Path: 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 A86021A031C for ; Mon, 15 Sep 2014 05:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zlV6k8uqcnKa for ; Mon, 15 Sep 2014 05:34:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904FF1A0316 for ; Mon, 15 Sep 2014 05:34:02 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-a3-5416dcb8ff4e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.29.21334.8BCD6145; Mon, 15 Sep 2014 14:34:00 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 14:34:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4F55C11029B; Mon, 15 Sep 2014 15:34:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5125A4E98A; Mon, 15 Sep 2014 15:35:25 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 79D584E947; Mon, 15 Sep 2014 15:35:24 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_5F48FE18-1896-4ACA-B33B-E4B45FE8C0AE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <5416CF8D.1070707@ericsson.com> Date: Mon, 15 Sep 2014 15:33:58 +0300 Message-ID: <633A010F-1456-479A-ABCE-52EAD14C7346@ericsson.com> References: <20140905182558.7340.5516.idtracker@ietfa.amsl.com> <540A04E3.2040203@tomh.org> <9BFCB5CC-FD77-49C2-9A67-39AEB45530D1@nominum.com> <540B2A2E.9040905@tomh.org> <540C3EB0.2000004@gmail.com> <5416CF8D.1070707@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM+Jvje6OO2IhBl2HjC0OLb7EajGz5x+j xaGXf5gtpi6azGwxfe81dout3bEWF9b/YrFovPuHyYHDo2VVL7PH2u6rbB6rXrWzeeycdZfd Y8mSn0weM49/YfF4fWA+q8eeaxoBHFFcNimpOZllqUX6dglcGW8XLmArWOFY0bfyFlMD4zGb LkZODgkBE4n3/ecYIWwxiQv31rOB2EICRxklmqfJdzFyAdkbGCUenz7IBOHsZZRY2tDFBuGs A3LePWSBcOYxStxsv8MO4jALTGGU2Nm2mgVkGK+AgcTx7z/BbGEBC4nt+y6BLWQT0JLYuHwB 2EJOAR2Jef23wGwWAVWJfzMWMkMMWs0ksXTvLCaIQfYSuy+9gFr3nFFi2pzzzCAJEQEzicVt a5gg3pCX+PDhODuErSZx9dwmZoiXVCRu/T3LNoFRZBayC2chuRDEZhbQlli28DUzhG0g8bTz FSuEbSrx+uhHRgjbWmLGr4NsELaixJTuh+wLGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZs YgRG9sEtv3V3MK5+7XiIUYCDUYmHd8EOsRAh1sSy4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDoO/1uVBCzmNoRkem2n27N8v+su/32rBgWVZcuqX+qZy2Li+8Y OX94uUSmej3Tuoti3xpLD3mXzT5/1jVylphfaso+2RgDme0nPcTK1kqqH7osc+TQgUuBIYe6 eV66LPh/fj1ntoVq5XuHPGnJB8rOTK9Waf1N3PuiYgVjjk3KtquMthwve+4rsRRnJBpqMRcV JwIATzsXNM0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/dJoOAOmhMzeAgufWmfdX-rRSVoA X-Mailman-Approved-At: Sat, 20 Sep 2014 01:36:35 -0700 Cc: Stephen Farrell , Brian Haberman , HIP , Francis.Dupont@enst-bretagne.fr, Tom Taylor , Barry Leiba Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 12:34:04 -0000 --Apple-Mail=_5F48FE18-1896-4ACA-B33B-E4B45FE8C0AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 2nd response - Gonzalo explained that Tom was already ok (and I should = have seen this from below=85 not sure why I didn=92t see the original = e-mail). Anyway, I have cleared :-) Jari On 15 Sep 2014, at 14:37, Gonzalo Camarillo = wrote: > Hi Tom (Henderson), >=20 > Jari, Brian, and Ted still have discusses on this document. Could you > please summarize for each of them the status of this draft with = respect > to their particular comments? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/09/2014 2:17 PM, Tom Taylor wrote: >> I'm happy with the outcome. The list discussion addressed the issue. = I >> believe the outcome is: "The plaintext attack is resistible, not a = real >> problem, and need not be addressed in the document." >>=20 >> Tom Taylor >>=20 >> On 06/09/2014 11:37 AM, Tom Henderson wrote: >>> On 09/06/2014 08:25 AM, Ted Lemon wrote: >>>> It looks like the latest rev of 5201-bis does not address the = gen-art >>>> review comments nor Francis Dupont's comments, and I haven't seen = any >>>> follow-up discussion on Francis' comments. What do the authors >>>> believe the status of these two comment threads is? >>>>=20 >>>=20 >>> Ted, >>>=20 >>> I believe that there is only one open issue left from the Gen-Art >>> review, regarding possible plaintext attacks: >>>=20 >>> http://trac.tools.ietf.org/wg/hip/trac/ticket/42 >>>=20 >>> The list discussion on this issue leans against making any change; = see >>> the last message of this thread: >>> http://www.ietf.org/mail-archive/web/hipsec/current/msg03903.html >>>=20 >>> I think I previously handled all of the other comments; if I missed = any, >>> please point them out. >>>=20 >>> I have tried to contact Francis a couple of times regarding >>> clarification of his comments and have not seen a reply. This is >>> tracked in issue: >>>=20 >>> http://trac.tools.ietf.org/wg/hip/trac/ticket/49 >>>=20 >>> I'm cc'ing both Tom Taylor and Francis for any further = clarifications. >>>=20 >>> - Tom >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >>=20 >=20 --Apple-Mail=_5F48FE18-1896-4ACA-B33B-E4B45FE8C0AE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCBEUw ggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVs aWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4X DTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv 1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqT u3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMc CYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUb Az2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2 MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb 8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXI v6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzY FSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67 OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3k MXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OY CMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAw OjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDgg VjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVy YSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5D uVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe 1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF4 6H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGj ggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7ga YqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0F BgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7Bgcq hXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20w cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkww DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUE kUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDC fkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6b KuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHn tP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPd OI5GtDYPMIIEqjCCA5KgAwIBAgIQTyXs3vXto5joAjtwrbnc3jANBgkqhkiG9w0BAQUFADA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMB4X DTEzMDMwNDEzMjUyMVoXDTE2MDMwNDEzMjUxOVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzARBgNV BAMMCkphcmkgQXJra28xEDAOBgNVBAUTB2xtZmphYXIxJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJr a29AZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhwriyJIY5Bbz yZrfnFAjWFLMNc6O6Z6dw5HqexTVyrUymDobuwcFtGl3n+yc6tYcvzM85LJMotJlOJH4NHEqClEc iMw+gFvN17PXxM2aAPuv1ZUL1wSdQ9dS94zxQEQuh4Myyfy+eqvrEBkzZaDPu4Evz6xsmCYPYSZP t4Bo6zbwQqkRvSQUO659ytmlyiPOiWN6wxEpwwO43LEw12xFrVSOQw3AG8ULW/xHbQvInuyWQdBC ug/1n6IJETsMWSrLFnk888IjABXKkmq42EG6RQ0BWLw8lAQwTju7rsDF9HrcTYBcu9z2u/d4cSgH P9SkRncRm68xrt7bD2RhPf3rkQIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZx bGRhcDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFs JTIwQ0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2Uw IgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEw MTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0O BBYEFLk/k+8oySkNxYm0GyPaFaKSRQufMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAECF65IiGH7GS+EEHre+itv2wv0OQ Z68DWR6G9IqMkBgb8dj6JcfFsu+9p8ID1e1L/0ybeTwz1t4IPhuOuWBPohj5irYiCBJkIokUr09B rWPyxfBrSoZ+uXVWfmZSdp15pWlEnHhuGuJkZ2a0MKrj+OEM9qfQR5Cvdlmx5PvsIhFkAFcZWldI xBwHsEeSoGJbVvvNImiY6M27u6rhuR8HanXVdcW4B8gK489LutxKhyhT9QDFUhmyWk2qYCUJgwM/ w44sLz8tv95jDbJxAR/aOwdwF3fQgj8VB5Xwvdn6B0PhfEcd3Ju4yUz6HE6ELZWG4ruE2haUCOn4 8WStKZ/RPDGCApMwggKPAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQTyXs3vXto5joAjtwrbnc3jAJBgUrDgMCGgUAoIIBGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTUxMjMzNThaMCMG CSqGSIb3DQEJBDEWBBTJTAhtapSW89cDMZupGnzUb9ZPPTBcBgkrBgEEAYI3EAQxTzBNMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l 7N717aOY6AI7cK253N4wXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l7N717aOY6AI7cK253N4wDQYJ KoZIhvcNAQEBBQAEggEAHM81LinUbl2os3gjpRV36QCvrAqcgYfQhAS2AsxX6AmwtpTNQg34IvZM jCJoxzFbOC0OUiAJISzYc0naKFNWNFS4C9BnS1b8KbNBCSxyfcnPomotZAqP2fJ1KiHN6pRbXLOy rfV1y0heqDQjs+2omQzfY15UBhdd5w2jrT0qhu/ai573RQM0lsi6P9lYNBc5F8rG6NNeKdLpkzgA xF0bqUeyCu6pLKOc0NnTWUvEujVmXAc29Wzj8i3HP3dopT/bMpOeBgc0jGgvPxDncl1PzNYqSzu+ AKuKyrriswSjl2RQ5n4O/oA7GimgPfyOEFT7vq7zub4+3SivVI4Rk953BQAAAAAAAA== --Apple-Mail=_5F48FE18-1896-4ACA-B33B-E4B45FE8C0AE-- From nobody Mon Sep 22 11:16:04 2014 Return-Path: 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 787091A1BC9; Mon, 22 Sep 2014 11:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mHu5D7Q_iXxT; Mon, 22 Sep 2014 11:16:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D77AE1A1BCA; Mon, 22 Sep 2014 11:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922181600.12327.27227.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 11:16:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/DvcYLT5yPBYoQ2Xq3koh3vxe8tY Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-18.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 22 Sep 2014 18:16:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Version 2 (HIPv2) Authors : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-18.txt Pages : 129 Date : 2014-09-22 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5201-bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 12:41:59 2014 Return-Path: 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 CEAF51A1B35; Mon, 22 Sep 2014 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1HxGKUP7y8oa; Mon, 22 Sep 2014 12:41:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018391A1B5D; Mon, 22 Sep 2014 12:41:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922194155.8886.50096.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 12:41:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/TqxCJnTb2SiLsr1cHNxVJ_BzDYA Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 22 Sep 2014 19:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Version 2 (HIPv2) Authors : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-19.txt Pages : 129 Date : 2014-09-22 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5201-bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 12:42:42 2014 Return-Path: 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 A899C1A1B57 for ; Mon, 22 Sep 2014 12:42:40 -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_20=-0.001, 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 vJqUNdW-wQy0 for ; Mon, 22 Sep 2014 12:42:39 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C811C1A1B0E for ; Mon, 22 Sep 2014 12:42:39 -0700 (PDT) Received: (qmail 1258 invoked by uid 0); 22 Sep 2014 19:42:36 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 22 Sep 2014 19:42:36 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id uKiY1o00S2molgS01KibbX; Mon, 22 Sep 2014 13:42:35 -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=DhAqLwFCtAgA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=dPhqZvqjLOaZuazYHccA: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:To:MIME-Version:From:Date:Message-ID; bh=RQrCpsxvLA2RKMnvbI+vXZs8PSS2iiy3AYIWak3SHa4=; b=J4rzOiMndPiOaJbQTHj9w9J812h2F+RXrwcmVY0F4RohB1eradwzZ9IRfQqKdlgH8WH8C4rLtYE+fS9KdLp57kXtC7sTceX/SIDL5OC73zK/p25ppBK+o2FHZv835Azu; Received: from [71.231.123.189] (port=59470 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XW9VJ-0004u1-9R for hipsec@ietf.org; Mon, 22 Sep 2014 13:42:33 -0600 Message-ID: <54207BA6.4040006@tomh.org> Date: Mon, 22 Sep 2014 12:42:30 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP References: <20140922181600.12327.27227.idtracker@ietfa.amsl.com> In-Reply-To: <20140922181600.12327.27227.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140922181600.12327.27227.idtracker@ietfa.amsl.com> 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/D5u_gPXornwyrL0BbEFR53TBgtI Subject: [Hipsec] new HIP draft versions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:42:40 -0000 All, the changes in draft version 18 are below: o Update ORCHID reference to newly published RFC 7343 o Update example checksum section to RFC 7343 HIT prefix of 2001:20::/28, and fix incorrect Header Length fields o Update IANA considerations comment on legacy HIP_TRANSFORM parameter naming o Add 2048-bit MODP DHE group as Group ID value 11. I realized immediately after publishing version 18 (upon revisiting the tracker) that I hadn't updated the typo in the IPv6 documentation prefix in Appendix C, so I created draft version 19 for this. While doing so, I discovered that the reference to the IPv4 documentation prefix was wrong, so I fixed this. Finally, I reviewed Appendix E, Section 3.2, and RFC 7343 (per Francis Dupont's comment) and made a small change to Appendix E that I hope resolves the comment. o Correct documentation prefix in Appendix C from 2001:D88/32 to 2001:DB8/32, and update IPv6 checksum o Correct documentation prefix reference from RFC 5747 to 5737 o Clarified HIT generation in Appendix E To my knowledge, these updates close all previously raised issues on the draft. It may be worthwhile for another implementation team to confirm the new checksum values that I generated for Appendix C. I do have a question about the HIT Suite IDs that I'll post in another message. - Tom From nobody Mon Sep 22 13:28:03 2014 Return-Path: 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 66AAF1A1B2E for ; Mon, 22 Sep 2014 13:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 QICTDjSHv-64 for ; Mon, 22 Sep 2014 13:27:55 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id F021D1A1B83 for ; Mon, 22 Sep 2014 13:27:51 -0700 (PDT) Received: (qmail 7706 invoked by uid 0); 22 Sep 2014 20:27:51 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Sep 2014 20:27:51 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id uSTl1o0012molgS01SToGg; Mon, 22 Sep 2014 20:27:50 -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=WXgBucgFJTYA:10 a=Ntlban6-KP8A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=dHDs3F7aARvFJjAXlUUA: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:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Z79KcFI9xtpvkPyNg5hi3q2VvDmeD3vtM2ystNoBpiU=; b=HCsL6qEn7E+dXklZW7YFLVpELPiK+pGBzSTO65LdbN8FsK/1ObZAsF4bkGEPZSTovf8V5Fgd9LaU30OkGeOzbunuuSkduCz3rKeQUulrKJD0y+64StH0XNHdeCjDzqEQ; Received: from [71.231.123.189] (port=59503 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XWAD3-0006AC-Kt; Mon, 22 Sep 2014 14:27:45 -0600 Message-ID: <5420863E.1060608@tomh.org> Date: Mon, 22 Sep 2014 13:27:42 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP 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/lwtFyokd1PR7YYdsIfAHJ-STga8 Cc: julien.ietf@gmail.com, fdupont@isc.org Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:27:56 -0000 In the course of performing recent draft revisions, I had some additional questions about the HIT Suite IDs. http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19#section-5.2.10 Briefly, RFC 7343 specifies that ORCHIDs consist of the special prefix, a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash. RFC 7343 does not ask IANA to set up a registry for OGA values. The RFC states "... the value of the OGA identifier according to the document defining the context usage identified by the Context ID." My read of this is that the assignment of OGA identifiers is delegated to the documents defining the context usage identified by the Context ID; in this case, it would be RFC5201-bis. The HIT Suite ID in RFC5201-bis is used as the OGA ID in HIP. The IANA considerations section states this, although someone looking explicitly for assigned OGA values may have to dig for it. The reason that the HIT Suite ID is not named the 'OGA ID' in HIP is due to the potential growth capability that is defined in section 5.2.10. Specifically, the zero value for HIT Suite ID is reserved, to allow for growth of the field should the four-bit field be exhausted. So it technically is an 8-bit value, and the 4 higher-order bits are used to form the OGA (for now). 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. 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: HIT Suite 4-bit truncated value 8-bit ID RESERVED 0 0 RSA,DSA/SHA-256 1 (REQUIRED) 65536 ECDSA/SHA-384 2 (RECOMMENDED) 131072 ECDSA_LOW/SHA-1 3 (RECOMMENDED) 262144 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. Thoughts? - Tom From nobody Mon Sep 22 22:34:44 2014 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Francis Dupont 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 , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Sep 23 07:49:56 2014 Return-Path: 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 4FAD71A86F3 for ; Tue, 23 Sep 2014 07:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDrXjxA72Uu1 for ; Tue, 23 Sep 2014 07:49:53 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822FC1A1ADC for ; Tue, 23 Sep 2014 07:49:53 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so7072318lbg.4 for ; Tue, 23 Sep 2014 07:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+5GZ7qA8Ffr6MaQVk/80a7vc1CwIZ1qxA3Jqa382tno=; b=NOmYKGFJ3SdhV3+xa77kXFx9ud6oLoIbH0Pg+GFnANmYMOwx18ulZJABqBvlaPYSpo 892CezLxNg8YeQzmXUYxcrpjcR88aUtKgP9X16o5DG86OdeAPU850tGPFT8AT6KNVQw8 Ltaggs4VkuR0ste1+ifBut9eCx2wj8zC2+OpVelXOu25oCOv+uF1NVwEKUx7MvWdHSYY H3ysxHCGUDhONllf8aw8Qo2uIuNbWEiZpQbvziqeo8NkaHzMRPORIXHWSRfvyPkJ/tTq qkoNCbCJy1TgJRBnbIU3dtmQg/Wg9t3vkxgxhzAiTe0fKv2jh/DnXh400pPrpa6dx7jp mSwQ== MIME-Version: 1.0 X-Received: by 10.152.87.170 with SMTP id az10mr201414lab.20.1411483791726; Tue, 23 Sep 2014 07:49:51 -0700 (PDT) Received: by 10.25.210.4 with HTTP; Tue, 23 Sep 2014 07:49:51 -0700 (PDT) In-Reply-To: <54210668.4050605@tomh.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> Date: Tue, 23 Sep 2014 07:49:51 -0700 Message-ID: From: Julien Laganier To: Tom Henderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/T3KSEptlqFaTWLsol9Lb3IC0AMs Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 14:49:55 -0000 Hi Tom, Please see inline. On Mon, Sep 22, 2014 at 10:34 PM, Tom Henderson wrote: > 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. 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. (and that is beyond this discussion, but given that adding more suite IDs presumably addresses a need for _increased_ security, it is counter intuitive to already decide to achieve that by _reducing_ the size of the encoded hash output, but I digress) > 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. IMHO it is premature to plan for the ID space exhaustion while it has not happened and we do not have an understanding of what will cause the ID space to be exhausted (if it ever does.) E.g., if none of the hash functions chosen in HIP suites provided enough security in 96 bits truncated output, will there be a new hash function that will? So the discussion on contingency plan seems moot at this point in time. Thus it seems keeping zero reserved is good enough for now. > 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. I think that makes sense since it is normative. --julien From nobody Tue Sep 23 10:40:13 2014 Return-Path: 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 747A21A87DB for ; Tue, 23 Sep 2014 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 aAH0TIUUks3l for ; Tue, 23 Sep 2014 10:40:08 -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 6D9B01A87D8 for ; Tue, 23 Sep 2014 10:40:07 -0700 (PDT) Received: (qmail 10612 invoked by uid 0); 23 Sep 2014 17:40:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Sep 2014 17:40:06 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id ung11o0082molgS01ng4nt; Tue, 23 Sep 2014 17:40:05 -0600 X-Authority-Analysis: v=2.1 cv=F6LEKMRN 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=955c1-5d0r2W_PXDO_UA:9 a=QEXdDO2ut3YA: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=Xm2Fh1pzgaaid8P2PsUWswga7Sm0aDLYEX+WP902p1A=; b=aGDJXexdzJqlOnxRdHS9vck88IpPb/WfXf/HI7GDvd5Q1NWFA8tSmrp+hcTtpLyQI+IaGMJqcqUmuJExMycbA8TErPoSiGnjoOsb5TsVkyNHJWu9BypNiR8G/PpmPyxb; Received: from [71.231.123.189] (port=41857 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XWU4H-0001FR-V8; Tue, 23 Sep 2014 11:40:02 -0600 Message-ID: <5421B06F.5010301@tomh.org> Date: Tue, 23 Sep 2014 10:39:59 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julien Laganier References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> In-Reply-To: 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/Oh5xf2kqfYXyo14PvF7fw8CzRDo Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 17:40:09 -0000 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: > > 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. 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. And if acceptable, make other editorial alignments to these statements... - Tom From nobody Tue Sep 23 12:37:33 2014 Return-Path: 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 288CC1A1B4D for ; Tue, 23 Sep 2014 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwl2amZ9N1kB for ; Tue, 23 Sep 2014 12:37:29 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5721A1AF4 for ; Tue, 23 Sep 2014 12:37:28 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gi9so9210302lab.38 for ; Tue, 23 Sep 2014 12:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlYtWpv9teB224dXDT+//YMbkuA5sDAA7JB5qAoC26A=; b=aViPJ5Dr6kQB46ZXZkfU6GSlJF+428yLJqb/o+3lwKnfpaeI0C5OZGJ3eIhnqsVEQl P/1Nu47ZO2ZBE2905haQnFCBGR//9uo7X4XyNfmSYbmO0q/k1R+LCUGioCK51GrxvA/T bio72EcP903AqWogaEfR082QosY7+dx6X2i3c/g/sfPYjmlQa2QWfuBOxvCzO9ijcVLC uxZM0QfyaqGGJpijtychg1baQpsnb1cKQmlLH0MZnXVJkl6FgCq62RNqSBjtK+zvfHQL z0OmH+SFwmRfW6Q1QWrhwoqv0q7S+K7NgXSXkltYwaQHRxlcRHdj3ntfSIAw8dYcbaLm 1OsQ== MIME-Version: 1.0 X-Received: by 10.112.204.197 with SMTP id la5mr1786278lbc.2.1411501047160; Tue, 23 Sep 2014 12:37:27 -0700 (PDT) Received: by 10.25.210.4 with HTTP; Tue, 23 Sep 2014 12:37:27 -0700 (PDT) In-Reply-To: <5421B06F.5010301@tomh.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> Date: Tue, 23 Sep 2014 12:37:27 -0700 Message-ID: From: Julien Laganier To: Tom Henderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/KUloW3xzT7QyQ9a7fq3N1FifQf8 Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 19:37:31 -0000 Hi Tom, Please see inline. On Tue, Sep 23, 2014 at 10:39 AM, Tom Henderson 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: > > >> >> >> 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.... > 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? --julien From nobody Tue Sep 23 12:55:04 2014 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julien Laganier References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> In-Reply-To: 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 , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: >> >> >>> >>> >>> 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 From nobody Wed Sep 24 06:13:03 2014 Return-Path: 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 6E20B1A00DE; Wed, 24 Sep 2014 06:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 u_-ErKQn0jsJ; Wed, 24 Sep 2014 06:12:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D241A00F6; Wed, 24 Sep 2014 06:12:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924131256.4149.79673.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 06:12:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/9Wpj_NzHYyfBMDuBuXcMIj8TxLE Cc: hip mailing list , hip chair , RFC Editor Subject: [Hipsec] Protocol Action: 'Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)' to Proposed Standard (draft-ietf-hip-rfc5202-bis-07.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 24 Sep 2014 13:13:00 -0000 The IESG has approved the following document: - 'Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)' (draft-ietf-hip-rfc5202-bis-07.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-rfc5202-bis/ Technical Summary: This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202. Working Group Summary: There is full consensus behind this document. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Gonzalo Camarillo is the document shepherd. Ted Lemon is the responsible AD. From nobody Wed Sep 24 13:29:33 2014 Return-Path: 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 160211A0406; Wed, 24 Sep 2014 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QZe11vfIOwJd; Wed, 24 Sep 2014 13:29:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348D1A19F3; Wed, 24 Sep 2014 13:29:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924202921.8538.79704.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 13:29:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1RZoVL4LwqQYjAmI-3APwRaDA-w Cc: hip mailing list , hip chair , RFC Editor Subject: [Hipsec] Protocol Action: 'Host Identity Protocol Version 2 (HIPv2)' to Proposed Standard (draft-ietf-hip-rfc5201-bis-19.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 24 Sep 2014 20:29:31 -0000 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/ Technical Summary: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. Working Group Summary: There is full consensus behind this document. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel: Gonzalo Camarillo is the document shepherd. Ted Lemon is the responsible AD. From nobody Wed Sep 24 21:21:39 2014 Return-Path: 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 7C6B01A19F7 for ; Wed, 24 Sep 2014 21:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDEiNe-t515q for ; Wed, 24 Sep 2014 21:21:36 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B6A1A19E2 for ; Wed, 24 Sep 2014 21:21:35 -0700 (PDT) Received: by mail-lb0-f178.google.com 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; d=gmail.com; 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 10.112.126.194 with SMTP id na2mr9898401lbb.70.1411618893003; Wed, 24 Sep 2014 21:21:33 -0700 (PDT) Received: by 10.25.210.4 with HTTP; Wed, 24 Sep 2014 21:21:32 -0700 (PDT) In-Reply-To: <5421D003.5020701@tomh.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> Date: Wed, 24 Sep 2014 21:21:32 -0700 Message-ID: From: Julien Laganier To: Tom Henderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/afqalZkjKjKgb0RHcKztml0Hip4 Cc: HIP , Francis Dupont 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." 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. > >> 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 From nobody Thu Sep 25 05:24:40 2014 Return-Path: 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 ; 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 ; 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 ; 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 To: Julien Laganier 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> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> In-Reply-To: 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 , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:24:38 -0000 --Apple-Mail=_C32AB034-078E-4EB3-A4B0-FD3330ADB283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, just wondering if the decision was made for us, as RFC5201-bis was = approved yesterday: =3D=3D=3D 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/ =3D=3D=3D BR Ren=E9 On 25 Sep 2014, at 06:21, Julien Laganier wrote: > Hi Tom, >=20 > Please see inline >=20 > On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson wrote: >> Julien, responses inline below. >>=20 >=20 > >=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> HIT Suite >>> RESERVED 0 >>> RSA,DSA/SHA-256/OGAID1 1 >>> ECDSA/SHA-384/OGAID2 2 >>> ECDSA_LOW/SHA-1/OGAID3 3 >>>=20 >>> 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.... >>=20 >>=20 >> IMHO the above is better than what I proposed, if the WG is willing = to make >> this kind of a change at this point. >>=20 >> Perhaps we should ask at this point for other WG opinions on whether = the >> above decoupling is acceptable? >=20 > Yes we should. >=20 > But does silence implies consent? :) >=20 >>>> Accordingly, would you agree to a modification to your proposal, as >>>> follows? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>>=20 >>> 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? >>>=20 >>> 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? >>=20 >>=20 >> 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. >=20 > 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. >=20 > --julien >=20 > _______________________________________________ > 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/ --Apple-Mail=_C32AB034-078E-4EB3-A4B0-FD3330ADB283 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MjUxMjI0MTlaMCMGCSqGSIb3DQEJBDEWBBTvpAUNmLg4 nqlrHm3sC+lw/6/PbDB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQBrd1XS0egD lfY3LnH6MQhZwOqWJnslcL/NJfavZrF5FTxbkAOnbSSSM9m08HS6hWWPsmwtE74NNhG5+UAlAsZX B5QmJ94FAqJol1mBhRRAX3cW8Hg5r7mHsomOSnrKP2asHCNljrPUt15SqDhLqQaTACKvcWfIV9J5 yHI1ZR+pd+Ryz+VY1g9Y2tiueDG7XVDycmALgqSzEnOLngYPjCnGvU7mvgggkuzlTg24UAzFGQum GlFE4Yz8YAQUPM9Im/i7/zQTwk0q6thgnTiV5ub6L5/66A7kShg7z1fUMjBrnZUTDtIiETotPd0i xKZXJf9bEbn4myUPnjdODi4xe6CIAAAAAAAA --Apple-Mail=_C32AB034-078E-4EB3-A4B0-FD3330ADB283-- From nobody Thu Sep 25 05:35:32 2014 Return-Path: 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 7892C1A6FCD for ; Thu, 25 Sep 2014 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 uIl2fDVVul5J for ; Thu, 25 Sep 2014 05:35:25 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DDB1A6FC7 for ; Thu, 25 Sep 2014 05:35:25 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F26AC1B8590 for ; Thu, 25 Sep 2014 05:35:24 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DE88253E07B; Thu, 25 Sep 2014 05:35:24 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 05:35:25 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de> Date: Thu, 25 Sep 2014 08:35:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7540C776-4133-4EFB-9CDF-5ADFA75E243A@nominum.com> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de> To: Rene Hummen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/cDTDwQKLfP3hxrv3xb4KJpTP4fw Cc: Julien Laganier , Francis Dupont , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:35:28 -0000 On Sep 25, 2014, at 8:24 AM, Rene Hummen = wrote: > just wondering if the decision was made for us, as RFC5201-bis was = approved yesterday: The kind of deliberation that you are doing post-IESG-approval on a = draft really isn't appropriate. If there is an error in the draft, you = should certainly tell me you need to fix it. But if you are having a = policy debate about something that wasn't resolved prior to the end of = working group last call and IETF last call, I'm afraid it really belongs = in a -bis document. And that's what this discussion looks like to me. That said, the reason I approved the document yesterday was because when = I went hunting through my email for comments relating to the review of = the document, I didn't find any, because this discussion hasn't been = referring to the document. If there is some *appropriate* fix that = needs to be made to the document, I can pull it out of the RFC editor = queue or we can address it during AUTH48. But the sort of changes that = would be appropriate in that context are quite restricted. =20 In order to make substantive changes that represent a new working group = consensus, we would have to do a new last call and re-review it in the = IESG. I expect that could be done quite expeditiously if the working = group decided it was necessary, but you need to tell me now if that's = what you want. From nobody Thu Sep 25 05:49:58 2014 Return-Path: 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 6B6461A007C for ; Thu, 25 Sep 2014 05:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 mJSUYB54hFb7 for ; Thu, 25 Sep 2014 05:49:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F621A0072 for ; Thu, 25 Sep 2014 05:49:55 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-bc-54240f71d19c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 06.E1.21334.17F04245; Thu, 25 Sep 2014 14:49:53 +0200 (CEST) Received: from [131.160.126.125] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.174.1; Thu, 25 Sep 2014 14:49:53 +0200 Message-ID: <54240F70.6030002@ericsson.com> Date: Thu, 25 Sep 2014 13:49:52 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Ted Lemon , Rene Hummen References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de> <7540C776-4133-4EFB-9CDF-5ADFA75E243A@nominum.com> In-Reply-To: <7540C776-4133-4EFB-9CDF-5ADFA75E243A@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW4hv0qIweI5qha3r2xgsZi6aDKz xZej05gtVnywsNjaHevA6rFyXSOTx85Zd9k9liz5yeTx4PE7Zo/XB+azBrBGcdmkpOZklqUW 6dslcGVcPXqMreAEf8W/E39ZGhh38HQxcnJICJhIPOnfzgJhi0lcuLeerYuRi0NI4CijxOuL T1lBEkICaxklzhyQBbF5BbQlfmx8BhZnEVCV6FpwhR3EZhOwkNhy6z7YIFGBKIlXK26wQtQL Spyc+QQsLiIQIXFuwyZGEJtZIE3i9OzbzCC2MNARp35PY4RY/IJZ4tqS30wgCU4Be4kb2zcB 2RxA14lL9DQGQfTqSUy52gI1R15i+9s5zBB3akssf9bCMoFRaBaS1bOQtMxC0rKAkXkVo2hx anFxbrqRsV5qUWZycXF+nl5easkmRmD4H9zyW3cH4+rXjocYBTgYlXh4FcqVQ4RYE8uKK3MP MUpzsCiJ8y46Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PFtjfPfRqrGnV/+dt837M0 /vjdI1cYU4L0/ZverJv6dPXNeUJ5u0O6l3wz2WB1e2WQoEhywLUC/u+XctQyJ+1oesf5Wu7z HdPN95I8jm5ZIsAy69Wh+jtlQuGLnz+u/x/ue78t6FjtJ3sJ9zD/++HFLRedhX/ZvfI2aZq6 u1VZOc8iweJu7w0lluKMREMt5qLiRADjq8QWYAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/c0REk00DQ2ELxQceMgmLqJawdVc Cc: Julien Laganier , Francis Dupont , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:49:57 -0000 Thanks for your note, Ted. Group, approving this draft now and starting a new "tris" draft right away does not really make sense. Shall we give Tom a couple of weeks to put together a revision of the draft and then go through a new IETF LC and IESG evaluation? As Ted said, this new process would be easier since the diff would not be that large. Cheers, Gonzalo On 25/09/2014 1:35 PM, Ted Lemon wrote: > On Sep 25, 2014, at 8:24 AM, Rene Hummen wrote: >> just wondering if the decision was made for us, as RFC5201-bis was approved yesterday: > > The kind of deliberation that you are doing post-IESG-approval on a draft really isn't appropriate. If there is an error in the draft, you should certainly tell me you need to fix it. But if you are having a policy debate about something that wasn't resolved prior to the end of working group last call and IETF last call, I'm afraid it really belongs in a -bis document. And that's what this discussion looks like to me. > > That said, the reason I approved the document yesterday was because when I went hunting through my email for comments relating to the review of the document, I didn't find any, because this discussion hasn't been referring to the document. If there is some *appropriate* fix that needs to be made to the document, I can pull it out of the RFC editor queue or we can address it during AUTH48. But the sort of changes that would be appropriate in that context are quite restricted. > > In order to make substantive changes that represent a new working group consensus, we would have to do a new last call and re-review it in the IESG. I expect that could be done quite expeditiously if the working group decided it was necessary, but you need to tell me now if that's what you want. > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > From nobody Thu Sep 25 06:15:29 2014 Return-Path: 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 9D4F31A008D for ; Thu, 25 Sep 2014 06:15:27 -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 vO7fJM9s1w4V for ; Thu, 25 Sep 2014 06:15:26 -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 7F41F1A0071 for ; Thu, 25 Sep 2014 06:15:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,597,1406584800"; d="p7s'?scan'208";a="262332545" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-2.rz.rwth-aachen.de with ESMTP; 25 Sep 2014 15:15:25 +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 92EC713DAC2; Thu, 25 Sep 2014 15:15:24 +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 15:15:24 +0200 From: Rene Hummen To: Gonzalo Camarillo Thread-Topic: [Hipsec] clarification on HIT Suite IDs Thread-Index: AQHP1qPQG8XbqWml2E21zaxD1+8moJwOMwXfgAB5boCAAC+JgIAAINGAgAAE04CAAh/wAIAAhuOAgAADAwCAAAQgAIAAByKA Date: Thu, 25 Sep 2014 13:15:23 +0000 Message-ID: <48974666-8C53-4FA6-8ED1-432BC84DA304@comsys.rwth-aachen.de> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de> <7540C776-4133-4EFB-9CDF-5ADFA75E243A@nominum.com> <54240F70.6030002@ericsson.com> In-Reply-To: <54240F70.6030002@ericsson.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=_44FB8E8F-8ADC-407C-B933-AB501AED16AF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/8JPcLbo_Kwh7yxoqSlMDcVvY85w Cc: Julien Laganier , Francis Dupont , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 13:15:27 -0000 --Apple-Mail=_44FB8E8F-8ADC-407C-B933-AB501AED16AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Ted for clarifying. On 25 Sep 2014, at 14:49, Gonzalo Camarillo = wrote: > Thanks for your note, Ted. >=20 > Group, approving this draft now and starting a new "tris" draft right > away does not really make sense. Shall we give Tom a couple of weeks = to > put together a revision of the draft and then go through a new IETF LC > and IESG evaluation? >=20 > As Ted said, this new process would be easier since the diff would not > be that large. Should we first agree that we indeed want to separate the HIT suite ID = from the OGA ID and that a simple clarification of how a HIT suite ID = maps to an OGA ID does not suffice? The latter would probably be a minor = edit that could still be fixed without starting a new evaluation round. > On 25/09/2014 1:35 PM, Ted Lemon wrote: >> On Sep 25, 2014, at 8:24 AM, Rene Hummen = wrote: >>> just wondering if the decision was made for us, as RFC5201-bis was = approved yesterday: >>=20 >> The kind of deliberation that you are doing post-IESG-approval on a = draft really isn't appropriate. If there is an error in the draft, you = should certainly tell me you need to fix it. But if you are having a = policy debate about something that wasn't resolved prior to the end of = working group last call and IETF last call, I'm afraid it really belongs = in a -bis document. And that's what this discussion looks like to me. >>=20 >> That said, the reason I approved the document yesterday was because = when I went hunting through my email for comments relating to the review = of the document, I didn't find any, because this discussion hasn't been = referring to the document. If there is some *appropriate* fix that = needs to be made to the document, I can pull it out of the RFC editor = queue or we can address it during AUTH48. But the sort of changes that = would be appropriate in that context are quite restricted. =20 >>=20 >> In order to make substantive changes that represent a new working = group consensus, we would have to do a new last call and re-review it in = the IESG. I expect that could be done quite expeditiously if the = working group decided it was necessary, but you need to tell me now if = that's what you want. >>=20 >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >>=20 >>=20 >=20 -- 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/ --Apple-Mail=_44FB8E8F-8ADC-407C-B933-AB501AED16AF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MjUxMzE1MjNaMCMGCSqGSIb3DQEJBDEWBBQreedmpes9 2a5eud2R8woaFcLnYTB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQABv9WZ2HcL 0K96Npm1w/k4z3s39l5Mb/i8Fnp0cDP3RJ7lgt4EFv+B6tTHUzV9j+cxa3ER8uKGCcDDYbteFRq2 zanXyZg1vq/b5kHaeaRAY2vkSUY84gohecnPKSQGQ394tBA7alLneDJp97df628rP/pEm7WirGs5 I2q2afRZSxJBJSNvrmqgkBx6PdtKzo259AqBH+5yIj2aGokY19Nm/GLMYO6qjsJDdhmsgcC7RVmi wZxHcITVyvZrKVPdfUr5Gt67ip62q1jLhSzw6Qkl9uTyZyxychZLekTd8T/jYLBBFtNFFKrUr9G1 Z4ZvcU5eUWrx0FpGdHoZGfuRslGjAAAAAAAA --Apple-Mail=_44FB8E8F-8ADC-407C-B933-AB501AED16AF-- From nobody Thu Sep 25 06:27:38 2014 Return-Path: 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 99D121A00B2 for ; Thu, 25 Sep 2014 06:27:36 -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 xQffJIcM_EZo for ; Thu, 25 Sep 2014 06:27:34 -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 DEA801A0092 for ; Thu, 25 Sep 2014 06:27:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,597,1406584800"; d="p7s'?scan'208";a="262334679" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-2.rz.rwth-aachen.de with ESMTP; 25 Sep 2014 15:27:33 +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 1563D13DAC2; Thu, 25 Sep 2014 15:27:33 +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 15:27:32 +0200 From: Rene Hummen To: Julien Laganier Thread-Topic: [Hipsec] clarification on HIT Suite IDs Thread-Index: AQHP1qPQG8XbqWml2E21zaxD1+8moJwOMwXfgAB5boCAAC+JgIAAINGAgAAE04CAAh/wAIAAmIoA Date: Thu, 25 Sep 2014 13:27:31 +0000 Message-ID: References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> In-Reply-To: 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=_FD590739-F251-43C2-BEAB-091DFB6F21B9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/OHnyLSwibpCE0ADeA3jW5m5K4C4 Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 13:27:36 -0000 --Apple-Mail=_FD590739-F251-43C2-BEAB-091DFB6F21B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Sep 2014, at 06:21, Julien Laganier wrote: > Hi Tom, >=20 > Please see inline >=20 > On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson wrote: >> Julien, responses inline below. >>=20 >=20 > >=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> HIT Suite >>> RESERVED 0 >>> RSA,DSA/SHA-256/OGAID1 1 >>> ECDSA/SHA-384/OGAID2 2 >>> ECDSA_LOW/SHA-1/OGAID3 3 >>>=20 >>> 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.... >>=20 >>=20 >> IMHO the above is better than what I proposed, if the WG is willing = to make >> this kind of a change at this point. Separating the OGA ID from the HIT suite ID certainly has its advantages = regarding the small OGA ID space. However, it also has implications on = HIPv2 crypto-agility. For example, how should the Initiator select the = destination HIT if it receives multiple Responder HITs from DNS but only = supports ECDSA? Plus, end-hosts would have to support multiple hash functions to cater = to a situation where the HIP hash function does not match the hash = function indicated by the OGA ID (which admittedly only is a minor issue = for Internet hosts). So, I propose to _not_ make any major modifications at this point. >> Perhaps we should ask at this point for other WG opinions on whether = the >> above decoupling is acceptable? >=20 > Yes we should. >=20 > But does silence implies consent? :) >=20 >>>> Accordingly, would you agree to a modification to your proposal, as >>>> follows? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>>=20 >>> 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? >>>=20 >>> 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? >>=20 >>=20 >> 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. >=20 > 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. >=20 > --julien >=20 > _______________________________________________ > 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/ --Apple-Mail=_FD590739-F251-43C2-BEAB-091DFB6F21B9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MjUxMzI3MzFaMCMGCSqGSIb3DQEJBDEWBBRfzriWLfSF FGAytpKJmEtCZwsN2TB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQBie6lIzri1 UzDJrfako/2nPSLq2YFqdDYRsb1seOwraOYUBy8ffGHkc+kqZgxTdGUEshBPleQRG4eDHKlY8Jhi 0qdO9+zf5Vy6xMiv4wbn0hZAgKvUe2AVQjYx8pp/hq4qV08v5xg5iAmfrw5MbtFAwlsfkZsn5d3/ bLn72ThUM4G0PEsdfrZDWNtubdms1Knc9IgAdhDoYa13Ac99UCmkPZB4x8x+U+e3jg/O/Jk187K/ 0kPugyFTeLeJ/jjz6tzP2mBBi3ux5trzvkRoFHZOympWveNZv5w+clLjhbZpDkSgLJWfJ1S9x53P 7uOVusHszhoYHhLulfdw5E78h4cXAAAAAAAA --Apple-Mail=_FD590739-F251-43C2-BEAB-091DFB6F21B9-- From nobody Thu Sep 25 06:36:10 2014 Return-Path: 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 688161A6FD9 for ; Thu, 25 Sep 2014 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 D9dE92wU1OD8 for ; Thu, 25 Sep 2014 06:36:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D301A0023 for ; Thu, 25 Sep 2014 06:36:07 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-39-54241a45edbf Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 12.E8.21334.54A14245; Thu, 25 Sep 2014 15:36:05 +0200 (CEST) Received: from [131.160.126.125] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Thu, 25 Sep 2014 15:36:04 +0200 Message-ID: <54241A43.30304@ericsson.com> Date: Thu, 25 Sep 2014 14:36:03 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Rene Hummen References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> <017BB5BE-1AC6-483B-9F2B-60B0CBFE4E6A@comsys.rwth-aachen.de> <7540C776-4133-4EFB-9CDF-5ADFA75E243A@nominum.com> <54240F70.6030002@ericsson.com> <48974666-8C53-4FA6-8ED1-432BC84DA304@comsys.rwth-aachen.de> In-Reply-To: <48974666-8C53-4FA6-8ED1-432BC84DA304@comsys.rwth-aachen.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvja6rlEqIweVrkha3r2xgsZi6aDKz xZej05gtVnywsNjaHevA6rFyXSOTx85Zd9k9liz5yeTx4PE7Zo/XB+azBrBGcdmkpOZklqUW 6dslcGX8mPGGveCWWMWRHWuYGxjnCHUxcnJICJhIXF6+lh3CFpO4cG89WxcjF4eQwFFGia1f N0E5axklnnbdZOxi5ODgFdCU6LyeB9LAIqAq0XLvMhuIzSZgIbHl1n0WEFtUIEri1YobrCA2 r4CgxMmZT8DiIgLGEvvuX2IHmcks0M0o8XLfarDNwkBXnPo9jRFqM4vEmUUTwKZyCnhKnHx8 iQVksYSAuERPYxBImFlAT2LK1RZGCFteYvvbOcwgtpCAtsTyZy0sExiFZiHZPQtJyywkLQsY mVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbAwS2/dXcwrn7teIhRgINRiYdXoVw5RIg1 say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME7M9d1+k62jfXW2 6sEwZ7Ok9dYazKFh657cYIwLm/zCv75fUSzPc9a0zszNMgKpE+9nTLqaUSmRGhDsd+FFm8/9 QpnGnnYB5/LVy969Yjx68YDTrjn7p/Bsf+W3/MCaGgM1Pb91CUutl6772nZqv+urpsrqqsuK O7v/VH2z+NwYHvdZaF7CEiWW4oxEQy3mouJEAPTkG3lhAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/eJTOxDl5oWpBhYT3UzNcFx77y7c Cc: Julien Laganier , Francis Dupont , HIP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 13:36:09 -0000 Hi, sure, the idea is to finish the discussions. If the conclusion is that there is no need to significantly change the draft, then a new IETF LC will not be needed. Cheers, Gonzalo On 25/09/2014 2:15 PM, Rene Hummen wrote: > Thanks Ted for clarifying. > > On 25 Sep 2014, at 14:49, Gonzalo Camarillo wrote: >> Thanks for your note, Ted. >> >> Group, approving this draft now and starting a new "tris" draft right >> away does not really make sense. Shall we give Tom a couple of weeks to >> put together a revision of the draft and then go through a new IETF LC >> and IESG evaluation? >> >> As Ted said, this new process would be easier since the diff would not >> be that large. > > Should we first agree that we indeed want to separate the HIT suite ID from the OGA ID and that a simple clarification of how a HIT suite ID maps to an OGA ID does not suffice? The latter would probably be a minor edit that could still be fixed without starting a new evaluation round. > >> On 25/09/2014 1:35 PM, Ted Lemon wrote: >>> On Sep 25, 2014, at 8:24 AM, Rene Hummen wrote: >>>> just wondering if the decision was made for us, as RFC5201-bis was approved yesterday: >>> >>> The kind of deliberation that you are doing post-IESG-approval on a draft really isn't appropriate. If there is an error in the draft, you should certainly tell me you need to fix it. But if you are having a policy debate about something that wasn't resolved prior to the end of working group last call and IETF last call, I'm afraid it really belongs in a -bis document. And that's what this discussion looks like to me. >>> >>> That said, the reason I approved the document yesterday was because when I went hunting through my email for comments relating to the review of the document, I didn't find any, because this discussion hasn't been referring to the document. If there is some *appropriate* fix that needs to be made to the document, I can pull it out of the RFC editor queue or we can address it during AUTH48. But the sort of changes that would be appropriate in that context are quite restricted. >>> >>> In order to make substantive changes that represent a new working group consensus, we would have to do a new last call and re-review it in the IESG. I expect that could be done quite expeditiously if the working group decided it was necessary, but you need to tell me now if that's what you want. >>> >>> _______________________________________________ >>> 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/ > From nobody Thu Sep 25 07:47:04 2014 Return-Path: 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 732211A0137 for ; Thu, 25 Sep 2014 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVdXSP_WJJCO for ; Thu, 25 Sep 2014 07:47:00 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949C11A00F3 for ; Thu, 25 Sep 2014 07:46:59 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so12881003lam.28 for ; Thu, 25 Sep 2014 07:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y9qFcMMNHWW56BTERWswSq8F0PdhzFoFS7W07Vp83+k=; b=c3mcYRw2K1ODJ0pJjAdkl/6JM8pJ8EoVoDURH0DbUSDfNd+RECA47rftgbLtFb4pm2 aizzO0M0DVqYHObbYTUx2CwBPn1r2dff52UJvXbbX/TQrl0S88JO0wdF310GzMp8U9Wv fugAdSzxaIfVZtNmqRx7r27LDXGx7Q28fmgdL+Mh/uUy2vOazwko3UGesM8Td8ahBppO qB7F6282JnZt4GWrYWkzqa4U0Jm/kdqpQLJXazVYaowDDGHMlc4W4eRWg+EhWUd7LyO0 lklU5Jjd8koELoQoTCFh7igeb7srfK49SX1I1UdBkS/nXGfhIhfkLMZMadn9a4eEMKmG bqew== MIME-Version: 1.0 X-Received: by 10.152.23.69 with SMTP id k5mr14087169laf.70.1411656417590; Thu, 25 Sep 2014 07:46:57 -0700 (PDT) Received: by 10.25.210.4 with HTTP; Thu, 25 Sep 2014 07:46:57 -0700 (PDT) In-Reply-To: References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <5421B06F.5010301@tomh.org> <5421D003.5020701@tomh.org> Date: Thu, 25 Sep 2014 07:46:57 -0700 Message-ID: From: Julien Laganier To: Rene Hummen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1cx2TsFzDikf7kXeWCtH_k44_lM Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:47:01 -0000 On Thu, Sep 25, 2014 at 6:27 AM, Rene Hummen wrote: > > Separating the OGA ID from the HIT suite ID certainly has its advantages = regarding the small OGA ID space. However, it also has implications on HIPv= 2 crypto-agility. For example, how should the Initiator select the destinat= ion HIT if it receives multiple Responder HITs from DNS but only supports E= CDSA? I don't see how this (an initiator having to select a HIT out of a set of HITs generated with different OGA IDs) would be impacted by decoupling or not the OGA ID from the HIT suite ID. Irrespective of the decoupling, an initiator that receives a set of HITs for a responder has to select one for which it supports the OGA ID. > Plus, end-hosts would have to support multiple hash functions to cater to= a situation where the HIP hash function does not match the hash function i= ndicated by the OGA ID (which admittedly only is a minor issue for Internet= hosts). This isn't a bug, it's a feature - hash agility. > So, I propose to _not_ make any major modifications at this point. I am not feeling strongly either way; from my perspective it is fine to worry about the need for more hash functions when the need arise which isn't the case now. (I was just trying to make sense of the seemingly contradictory decision to tie the burn rates of the small OGA ID space to the larger HIP suite ID space, where the HIP suite ID space is presumably made larger to increase future security, at the cost of shrinking the hash output which to me decreases security.) Regardless, I think that the text talking about using more bits of the ORCHIDs to encode a HIP suite ID should be removed as this is not supported by the ORCHID generation scheme (and would IMHO be a bad thing to do, but that is beyond the point.) --julien From nobody Thu Sep 25 09:02:54 2014 Return-Path: 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 1A9A71A014D; Thu, 25 Sep 2014 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yEOFQMsQcOlz; Thu, 25 Sep 2014 09:02:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 677081A014E; Thu, 25 Sep 2014 09:02:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925160246.24684.36158.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 09:02:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/P-evg3P4w-BMd1iZ4BzZyeGjgbM Cc: hipsec@ietf.org, hip-chairs@tools.ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RETRACTION: Protocol Action: 'Host Identity Protocol Version 2 (HIPv2)' to Proposed Standard (draft-ietf-hip-rfc5201-bis-19.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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 16:02:52 -0000 The IESG has requested retraction of this Protocol Action Announcement. The document state has been changed to "Approved-announcement to be sent::AD Followup." Please remove this document from the RFC Editor Queue. Best regards, IESG Secretary On Sep 24, 2014, at 1:29 PM, The IESG wrote: > 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/ > > > Technical Summary: > > This document specifies the details of the Host Identity Protocol > (HIP). HIP allows consenting hosts to securely establish and > maintain shared IP-layer state, allowing separation of the > identifier and locator roles of IP addresses, thereby enabling > continuity of communications across IP address changes. HIP is > based on a SIGMA- compliant Diffie-Hellman key exchange, using > public key identifiers from a new Host Identity namespace for > mutual peer authentication. The protocol is designed to be > resistant to denial-of-service (DoS) and man-in-the-middle (MitM) > attacks. When used together with another suitable security > protocol, such as the Encapsulated Security Payload (ESP), it > provides integrity protection and optional encryption for > upper-layer protocols, such as TCP and UDP. > > This document obsoletes RFC 5201 and addresses the concerns raised > by the IESG, particularly that of crypto agility. It also > incorporates lessons learned from the implementations of RFC 5201. > > > Working Group Summary: > > There is full consensus behind this document. > > Document Quality: > > As discussed in RFC 6538, there are several implementations of the > Experimental HIP specs. At least HIP for Linux and OpenHIP will be > updated to comply with the standards-track specs. > > Personnel: > > Gonzalo Camarillo is the document shepherd. > Ted Lemon is the responsible AD. From nobody Fri Sep 26 03:39:24 2014 Return-Path: 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 5127A1A6F14 for ; Mon, 22 Sep 2014 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 x_xORVfxIMlp for ; Mon, 22 Sep 2014 14:28:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A2C1A6F0E for ; Mon, 22 Sep 2014 14:28:28 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id A0B723493C3; Mon, 22 Sep 2014 21:31:18 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10295) id 5048E216C3B; Mon, 22 Sep 2014 21:28:26 +0000 (UTC) From: Francis Dupont To: Tom Henderson In-reply-to: <5420863E.1060608@tomh.org> References: <5420863E.1060608@tomh.org> Comments: In-reply-to Tom Henderson message dated "Mon, 22 Sep 2014 13:27:42 -0700." Date: Mon, 22 Sep 2014 21:28:26 +0000 Message-Id: <20140922212826.5048E216C3B@bikeshed.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/PbXu8Udw3GiZRZmZqKHv908Vw9o X-Mailman-Approved-At: Fri, 26 Sep 2014 03:39:20 -0700 Cc: HIP , fdupont@isc.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:28:55 -0000 Tom Henderson writes: > In the course of performing recent draft revisions, I had some > additional questions about the HIT Suite IDs. > > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19#section-5.2.10 => HIT/ORCHID stuff is more in section 3 and appendix E. > Briefly, RFC 7343 specifies that ORCHIDs consist of the special prefix, > a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash. => yes. > RFC 7343 does not ask IANA to set up a registry for OGA values. => yes and the reason is OGA values are not globally defined: they are related to a Context ID (HIP in this case). > The RFC states > "... the value of the OGA identifier according to the > document defining the context usage identified by the Context ID." > My read of this is that the assignment of OGA identifiers is delegated > to the documents defining the context usage identified by the Context > ID; in this case, it would be RFC5201-bis. => exactly. > The HIT Suite ID in RFC5201-bis is used as the OGA ID in HIP. The IANA > considerations section states this, although someone looking explicitly > for assigned OGA values may have to dig for it. => section 3.2 says: ... The set of hash function, signature algorithm, and the algorithm used for generating the HIT from the HI depends on the HIT Suite (see Appendix E) and is indicated by the four bits of the ORCHID Generation Algorithm (OGA) field in the ORCHID. so the OGA table is in the appendix E (note the appendix E itself was a bit broken in previous RFC 5201 bis versions, but there was such a table in it). > The reason that the HIT Suite ID is not named the 'OGA ID' in HIP is due > to the potential growth capability that is defined in section 5.2.10. > Specifically, the zero value for HIT Suite ID is reserved, to allow for > growth of the field should the four-bit field be exhausted. So it > technically is an 8-bit value, and the 4 higher-order bits are used to > form the OGA (for now). > > 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. 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). > 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... Regards Francis Dupont From nobody Fri Sep 26 03:39:25 2014 Return-Path: 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 29E031A7D83 for ; Tue, 23 Sep 2014 04:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 BiNVTzJytZjC for ; Tue, 23 Sep 2014 04:27:51 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB301A70FE for ; Tue, 23 Sep 2014 04:27:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1F4561FCB4F; Tue, 23 Sep 2014 11:27:48 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10295) id EA16C216C3B; Tue, 23 Sep 2014 11:27:46 +0000 (UTC) From: Francis Dupont To: Tom Henderson In-reply-to: <54210668.4050605@tomh.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> Comments: In-reply-to Tom Henderson message dated "Mon, 22 Sep 2014 22:34:32 -0700." Date: Tue, 23 Sep 2014 11:27:46 +0000 Message-Id: <20140923112746.EA16C216C3B@bikeshed.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/wrYKJwq9SUT8N21tt4e6RRGYqAY X-Mailman-Approved-At: Fri, 26 Sep 2014 03:39:20 -0700 Cc: HIP , Francis Dupont , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 11:27:52 -0000 Tom Henderson writes: > 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. => yes, there is a long discussion in RFC 7343 about this tradeoff. > which implied to me that the HIT suite ID may in the future consume more > bits presently allocated to hash. => the fact the problem could exist doesn't mean it will exist... > > 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? => one will need more than 15 HIT Suite-IDs -> one will need more than 15 HIT Suite-IDs at the same time > > => 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). => clearly the current plan is the first (reuse 4 bit values). The second is just a provision in the case the first fails. > 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. => perhaps it was considered as too optimistic? BTW I have no idea about the future need in new values in the HIT_SUITE_ID / OGA space (but does somebody already have one?) > 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. => it is a question for the hipsec mailing list (I subscribed to it but from my personal e-mail). Regards Francis Dupont From nobody Mon Sep 29 09:20:31 2014 Return-Path: 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 A79BD1A8850 for ; Mon, 29 Sep 2014 09:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 zHcZ8evKfVQJ for ; Mon, 29 Sep 2014 09:20:26 -0700 (PDT) Received: from mx1.belden.com (mx1.belden.com [12.161.118.90]) by ietfa.amsl.com (Postfix) with ESMTP id 562251A87E0 for ; Mon, 29 Sep 2014 09:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=belden.com; s=beldencom; c=relaxed/simple; q=dns/txt; i=@belden.com; t=1412007624; x=1414599624; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pGrKB5TjsOiRn3g1wHoNxEXQluYtHscf9/nA/Y71GZk=; b=iVpQYYtg/Ly9W1CsOsfHXwy1LxjnBRjjN2jmK1B8VqCOm50NCCDjzq3puYxA7j+s /cWNNTe7LFkd6jLAsFddXj5nbL3ZM3f/qkaBRBE+7gCFmscV2xLtncCDaVEFT18d 6EKF4Pj13UpawXvD8o7ez2RUhQDW6ys/46Ijw2nH3IE=; X-AuditID: 0a01015a-b7f628e000000d19-05-542986c84f31 Received: from bdcnotes2.belden.com ( [10.1.1.72]) by mx1.belden.com (Service Ready) with SMTP id 40.81.03353.8C689245; Mon, 29 Sep 2014 12:20:24 -0400 (EDT) In-Reply-To: <20140923112746.EA16C216C3B@bikeshed.isc.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <20140923112746.EA16C216C3B@bikeshed.isc.org> To: HIP MIME-Version: 1.0 X-KeepSent: D6408C65:060C7582-C1257D62:005816DE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Tobias.Heer@Belden.com Message-ID: Date: Mon, 29 Sep 2014 18:20:23 +0200 X-MIMETrack: Serialize by Router on BDCNotes2/BeldenCDT(Release 9.0 HF625|September 19, 2013) at 09/29/2014 12:20:24 PM, Serialize complete at 09/29/2014 12:20:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0059BB41C1257D62_=" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsXCxcjooXuiTTPEYOM8RYvbVzawWHz+0cVu MXXRZGaLL0enMVs03v3D5MDqsXPWXXaPJUt+Mnk8ePyO2WPPNY0AlqgGRpukxJKy4Mz0PH07 m8S8vPySxJJUhZTU4mRbJafUnJTUPAWXzOLknMTM3NQiXc9gf10LC1NLJYXMFFslIyWFgpzE 5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZp5Cal5yfkpmXbqsUGuKma6Fk5+IZ7JzQyppx5qlN wU/3inmHHjM2MC606mLk5JAQMJE4O+01O4QtJnHh3nq2LkYuDiGB+YwSy299ZgZJcApYSTxZ dpARLnHw/TYmkISIgKREz92lLCAJZoEWRonvF56AJXgFBCVOznzCAmILC9hK3P99kw1ihafE omWPWSFsM4mXly8ygthsAjIS2w7uheoNklh35gtYL4uAqsTbn0/BNksIrGSUOLdmAdhJzAIB EmeeHmSdwCgwC8m+WUhSELaOxIlVx5ghbG2JRVd+si9gZFnFyJdbYaiXBA54veT83E2MkCiO 2sH4tEXhEKMAB6MSD+8fXs0QIdbEsuLK3EOMEhzMSiK8dilAId6UxMqq1KL8+KLSnNTiQ4xB QHdOZJbiTs4HJpi8knhjAwMiOUrivF8/1QQLCaQDk0N2ampBahHMUCYOTpClXFIixcD4Ti1K LC3JiAclovhiYCqSamAMOMXW8Luo+dIuxmgF7rn74sLOnjRNz7NeGHvGuKukZRHDt83zJjk8 vuBv0GbfbPloUdTLWA/hgOJnYblPHa+Zl7mfYgzo6l7KUF1X5nOlyHbh2+MTlpd98/gW9GmT UdC0JwWS1zkO72xdprDvs732rGSX+L1JxZPKVmxzdV18a7OiEduMCy5KLMUZiYZazEXFiQD4 bRJyMAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/quiFfxvvEW_ZJbldgNlOHfYyq1A Cc: Hipsec , Francis Dupont , julien.ietf@gmail.com Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:20:28 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0059BB41C1257D62_= Content-Type: text/plain; charset="US-ASCII" Hello, I'd like to confirm some of your statements. The thought was really to show both options a) reuse of OGAs and b) what could happen if we need more bits. However, the wording and the current set of IDs was chosen so that it discourages the use of more IDs at the same time so the option to take more bits from the OGA was really just a last resort. Nothing anybody would really want. See my comments below. Von: Francis Dupont An: Tom Henderson , Kopie: HIP , Francis Dupont , julien.ietf@gmail.com Datum: 26.09.2014 12:39 Betreff: Re: [Hipsec] clarification on HIT Suite IDs Gesendet von: "Hipsec" Tom Henderson writes: > 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. => yes, there is a long discussion in RFC 7343 about this tradeoff. > which implied to me that the HIT suite ID may in the future consume more > bits presently allocated to hash. => the fact the problem could exist doesn't mean it will exist... TH=> This was just to cover all options. It is not a desired or intended action. > > 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? => one will need more than 15 HIT Suite-IDs -> one will need more than 15 HIT Suite-IDs at the same time TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are reasonably out of use. Appendix E describes this rollover. > > => 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). => clearly the current plan is the first (reuse 4 bit values). The second is just a provision in the case the first fails. TH=> Yes. I can confirm this. > 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. => perhaps it was considered as too optimistic? BTW I have no idea about the future need in new values in the HIT_SUITE_ID / OGA space (but does somebody already have one?) TH=> I am fine with not specifying the extension of the ID but to leave 0 as reserved instead. > 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. => it is a question for the hipsec mailing list (I subscribed to it but from my personal e-mail). TH=> Moving the table to 5.2.10 is fine from my perspective. Best regards, Tobias DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. --=_alternative 0059BB41C1257D62_= Content-Type: text/html; charset="US-ASCII" Hello,

I'd like to confirm some of your statements. The thought was really to show both options a) reuse of OGAs and b) what could happen if we need more bits. However, the wording and the current set of IDs was chosen so that it discourages the use of more IDs at the same time so the option to take more bits from the OGA was really just a last resort. Nothing anybody would really want.

See my comments below.




Von:        Francis Dupont <fdupont@isc.org>
An:        Tom Henderson <tomh@tomh.org>,
Kopie:        HIP <hipsec@ietf.org>, Francis Dupont <fdupont@isc.org>, julien.ietf@gmail.com
Datum:        26.09.2014 12:39
Betreff:        Re: [Hipsec] clarification on HIT Suite IDs
Gesendet von:        "Hipsec" <hipsec-bounces@ietf.org>



Tom Henderson writes:
>        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.

=> yes, there is a long discussion in RFC 7343 about this tradeoff.

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

=> the fact the problem could exist doesn't mean it will exist...
TH=> This was just to cover all options. It is not a desired or intended action.

> > 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?

=> one will need more than 15 HIT Suite-IDs ->
one will need more than 15 HIT Suite-IDs at the same time
TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are reasonably out of use. Appendix E describes this rollover.

> > => 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).

=> clearly the current plan is the first (reuse 4 bit values).
The second is just a provision in the case the first fails.

TH=> Yes. I can confirm this.

> 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.

=> perhaps it was considered as too optimistic? BTW I have no idea
about the future need in new values in the HIT_SUITE_ID / OGA space
(but does somebody already have one?)

TH=> I am fine with not specifying the extension of the ID but to leave 0 as reserved instead.

> 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.

=> it is a question for the hipsec mailing list (I subscribed to it
but from my personal e-mail).
TH=> Moving the table to 5.2.10 is fine from my perspective.



Best regards,

Tobias


DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.

--=_alternative 0059BB41C1257D62_=-- From nobody Mon Sep 29 10:07:11 2014 Return-Path: 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 902451A89A9 for ; Mon, 29 Sep 2014 10:07:04 -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 mj-kyAks48LF for ; Mon, 29 Sep 2014 10:07:03 -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 E286E1A89A6 for ; Mon, 29 Sep 2014 10:07:02 -0700 (PDT) Received: (qmail 10678 invoked by uid 0); 29 Sep 2014 17:06:59 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 29 Sep 2014 17:06:58 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id x56q1o0042molgS0156t5w; Mon, 29 Sep 2014 11:06:57 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ 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=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=WDlp8lUfAAAA:8 a=SCo1hh1FAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=YFnVFSl8N6hIbQVderYA:9 a=wPNLvfGTeEIA:10 a=-FfqplK4AEMA:10 a=iw4bf7yTzGQA:10 a=OuPSdZv8c7MA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A: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=WtdYmrhyVBcpIDexPFgIqd2kIzW1QhRmWgykiOike0A=; b=k0UXp5knqSUeigJV+QZVUVop4Dt6ZXwBbfNE5TIylAOi48TN8OOLhoCL0Igy876sd9MzWu/OybWkWTWGO8SkgmP08VoWa/myrJ87Y3nX9rVSOyE2X96eUactDyBplYk4; Received: from [71.231.123.189] (port=55373 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYePS-0005J6-Rn; Mon, 29 Sep 2014 11:06:50 -0600 Message-ID: <542991A8.4020908@tomh.org> Date: Mon, 29 Sep 2014 10:06:48 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tobias.Heer@Belden.com, HIP References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <20140923112746.EA16C216C3B@bikeshed.isc.org> In-Reply-To: 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/Y5lAKYDC4UY2QzST7v26EcgkzCY Cc: julien.ietf@gmail.com, Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 17:07:05 -0000 On 09/29/2014 09:20 AM, Tobias.Heer@Belden.com wrote: > Hello, > > I'd like to confirm some of your statements. The thought was really to > show both options a) reuse of OGAs and b) what could happen if we need > more bits. However, the wording and the current set of IDs was chosen so > that it discourages the use of more IDs at the same time so the option > to take more bits from the OGA was really just a last resort. Nothing > anybody would really want. > > See my comments below. > > > > > Von: Francis Dupont > An: Tom Henderson , > Kopie: HIP , Francis Dupont , > julien.ietf@gmail.com > Datum: 26.09.2014 12:39 > Betreff: Re: [Hipsec] clarification on HIT Suite IDs > Gesendet von: "Hipsec" > ------------------------------------------------------------------------ > > > > Tom Henderson writes: > > 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. > > => yes, there is a long discussion in RFC 7343 about this tradeoff. > > > which implied to me that the HIT suite ID may in the future consume more > > bits presently allocated to hash. > > => the fact the problem could exist doesn't mean it will exist... > > TH=> This was just to cover all options. It is not a desired or intended > action. There is discussion of this in the IANA considerations section; perhaps this could be modified as follows: Old text: If 16 Suite IDs prove insufficient and more HIT Suite IDs are needed concurrently, more bits can be used for the HIT Suite ID by using one HIT Suite ID (0) to indicate that more bits should be used. The HIT_SUITE_LIST parameter already supports 8-bit HIT Suite IDs, should longer IDs be needed. Possible extensions of the HIT Suite ID space to accommodate eight bits and new HIT Suite IDs are defined through IETF Review. New text: If 15 Suite IDs (the zero value is initially reserved) prove to be insufficient and more HIT Suite IDs are needed concurrently, more bits can be used for the HIT Suite ID by using one HIT Suite ID (0) to indicate that more bits should be used. The HIT_SUITE_LIST parameter already supports 8-bit HIT Suite IDs, should longer IDs be needed. However, RFC 7343 does not presently support such an extension, and the rollover approach described in Appendix E is suggested to be tried first. Possible extensions of the HIT Suite ID space to accommodate eight bits and new HIT Suite IDs are defined through IETF Review. > > > > 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? > > => one will need more than 15 HIT Suite-IDs -> > one will need more than 15 HIT Suite-IDs at the same time > > TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are > reasonably out of use. Appendix E describes this rollover. So for this proposal by Francis, we would change Appendix E text from: Since the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID 0 is reserved) to be used in parallel, phased-out HIT Suites must be reused at some point. In such a case, there will be a rollover of to: Since the 4-bit OGA field only permits 15 HIT Suites to be used at the same time (the HIT Suite with ID 0 is reserved), phased-out HIT Suites must be reused at some point. In such a case, there will be a rollover of > > > > => 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). > > => clearly the current plan is the first (reuse 4 bit values). > The second is just a provision in the case the first fails. > > TH=> Yes. I can confirm this. > > > 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. > > => perhaps it was considered as too optimistic? BTW I have no idea > about the future need in new values in the HIT_SUITE_ID / OGA space > (but does somebody already have one?) > > TH=> I am fine with not specifying the extension of the ID but to leave > 0 as reserved instead. Julien suggested that if we consider non-zero bits as an error at the receiver, it may facilitate use of the four non-zero high-order bits in future extensions. in 5.2.10, it says: The four lower-order bits are reserved and set to 0 and ignored by the receiver. The proposal would be to change this to: The four lower-order bits are reserved and set to 0 by the sender. The reception of an ID with the four lower-order bits not set to 0 should be considered as an error that MAY result in a NOTIFICATION of type UNSUPPORTED_HIT_SUITE. Any comments/concerns with this potential change? > > > 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. > > => it is a question for the hipsec mailing list (I subscribed to it > but from my personal e-mail). > > TH=> Moving the table to 5.2.10 is fine from my perspective. I tend to prefer this; I will work up a proposal for this. - Tom From nobody Mon Sep 29 10:54:02 2014 Return-Path: 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 7AA451A8A76 for ; Mon, 29 Sep 2014 10:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGECm4DI3g4P for ; Mon, 29 Sep 2014 10:53:56 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2046A1A8A27 for ; Mon, 29 Sep 2014 10:53:55 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so18239432lbv.2 for ; Mon, 29 Sep 2014 10:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e8HrmGO3i5tjojnQQyfFmNBvwHDcI8zTWyxpGVxm9Gg=; b=E5G93di2lytXijajGaF2pWd7QvNYD6jUA+dgCpH4bJIkk6873uFXWFX12DQ19q0alW Q1l9zBzMWubK5fPrmKjdC/j+MzHfvf2PNOX0hsjz/br2fMIxYCDUOz7TeEDrhLfCSK4w 8azZ5xmo3dPRi4mxjJUVRKvE16m/rT4r6YYeizS/AeUBJKqUcACrCM+q4YLsSfcOSS+s imdtSPUFp4ZMW0Jl9duXXHFex61LIDWTW35KbnBBgP7mfSE7wOoEFJS2RW8YVkZW6EUo d/jrfLMu7g5VTgkTzfUoT6lkJnJguBYDYhwqNxGYia5526L+vlQKmrrW+4cty7fLyxd7 HpoQ== MIME-Version: 1.0 X-Received: by 10.112.161.70 with SMTP id xq6mr39498783lbb.49.1412013234416; Mon, 29 Sep 2014 10:53:54 -0700 (PDT) Received: by 10.25.210.4 with HTTP; Mon, 29 Sep 2014 10:53:54 -0700 (PDT) In-Reply-To: <542991A8.4020908@tomh.org> References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <20140923112746.EA16C216C3B@bikeshed.isc.org> <542991A8.4020908@tomh.org> Date: Mon, 29 Sep 2014 10:53:54 -0700 Message-ID: From: Julien Laganier To: Tom Henderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/QxtXDLuHbA1j4PxeVwXyZPn2UZo Cc: HIP , Francis Dupont 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 17:53:59 -0000 Hi Tom, FWIW your proposal looks good to me. --julien On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson wrote: > On 09/29/2014 09:20 AM, Tobias.Heer@Belden.com wrote: >> >> Hello, >> >> I'd like to confirm some of your statements. The thought was really to >> show both options a) reuse of OGAs and b) what could happen if we need >> more bits. However, the wording and the current set of IDs was chosen so >> that it discourages the use of more IDs at the same time so the option >> to take more bits from the OGA was really just a last resort. Nothing >> anybody would really want. >> >> See my comments below. >> >> >> >> >> Von: Francis Dupont >> An: Tom Henderson , >> Kopie: HIP , Francis Dupont , >> julien.ietf@gmail.com >> Datum: 26.09.2014 12:39 >> Betreff: Re: [Hipsec] clarification on HIT Suite IDs >> Gesendet von: "Hipsec" >> ------------------------------------------------------------------------ >> >> >> >> Tom Henderson writes: >> > 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. >> >> => yes, there is a long discussion in RFC 7343 about this tradeoff. >> >> > which implied to me that the HIT suite ID may in the future consume >> more >> > bits presently allocated to hash. >> >> => the fact the problem could exist doesn't mean it will exist... >> >> TH=> This was just to cover all options. It is not a desired or intended >> action. > > > There is discussion of this in the IANA considerations section; perhaps this > could be modified as follows: > > Old text: > > If 16 Suite IDs prove insufficient and > more HIT Suite IDs are needed concurrently, more bits can be used > for the HIT Suite ID by using one HIT Suite ID (0) to indicate > that more bits should be used. The HIT_SUITE_LIST parameter > already supports 8-bit HIT Suite IDs, should longer IDs be needed. > Possible extensions of the HIT Suite ID space to accommodate eight > bits and new HIT Suite IDs are defined through IETF Review. > > New text: > > If 15 Suite IDs (the zero value is initially reserved) prove > to be insufficient and > more HIT Suite IDs are needed concurrently, more bits can be used > for the HIT Suite ID by using one HIT Suite ID (0) to indicate > that more bits should be used. The HIT_SUITE_LIST parameter > already supports 8-bit HIT Suite IDs, should longer IDs be needed. > However, RFC 7343 does not presently support such an extension, > and the rollover approach described in Appendix E is suggested to > be tried first. > Possible extensions of the HIT Suite ID space to accommodate eight > bits and new HIT Suite IDs are defined through IETF Review. > > > >> >> > > 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? >> >> => one will need more than 15 HIT Suite-IDs -> >> one will need more than 15 HIT Suite-IDs at the same time >> >> TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are >> reasonably out of use. Appendix E describes this rollover. > > > So for this proposal by Francis, we would change Appendix E text from: > > Since > the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID > 0 is reserved) to be used in parallel, phased-out HIT Suites must be > reused at some point. In such a case, there will be a rollover of > > to: > > Since > the 4-bit OGA field only permits 15 HIT Suites to be used at the > same time (the HIT Suite with ID 0 is reserved), phased-out HIT > Suites must be > reused at some point. In such a case, there will be a rollover of > >> >> > > => 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). >> >> => clearly the current plan is the first (reuse 4 bit values). >> The second is just a provision in the case the first fails. >> >> TH=> Yes. I can confirm this. >> >> > 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. >> >> => perhaps it was considered as too optimistic? BTW I have no idea >> about the future need in new values in the HIT_SUITE_ID / OGA space >> (but does somebody already have one?) >> >> TH=> I am fine with not specifying the extension of the ID but to leave >> 0 as reserved instead. > > > Julien suggested that if we consider non-zero bits as an error at the > receiver, it may facilitate use of the four non-zero high-order bits in > future extensions. > > in 5.2.10, it says: > > The four > lower-order bits are reserved and set to 0 and > ignored by the receiver. > > The proposal would be to change this to: > > The four > lower-order bits are reserved and set to 0 by > the sender. The reception of an ID with > the four lower-order bits not set to 0 should be > considered as an error that MAY result in a > NOTIFICATION of type UNSUPPORTED_HIT_SUITE. > > Any comments/concerns with this potential change? > >> >> > 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. >> >> => it is a question for the hipsec mailing list (I subscribed to it >> but from my personal e-mail). >> >> TH=> Moving the table to 5.2.10 is fine from my perspective. > > > I tend to prefer this; I will work up a proposal for this. > > - Tom > > From nobody Mon Sep 29 14:22:01 2014 Return-Path: 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 7C3AC1ACCF6 for ; Mon, 29 Sep 2014 14:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r2GtjuuYAJ2T for ; Mon, 29 Sep 2014 14:21:48 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B21ACCF2 for ; Mon, 29 Sep 2014 14:21:40 -0700 (PDT) Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8]) by mail.cs.hut.fi (Postfix) with ESMTP id 48605308B22 for ; Tue, 30 Sep 2014 00:21:38 +0300 (EEST) Message-ID: <5429CD62.3080306@cs.hut.fi> Date: Tue, 30 Sep 2014 00:21:38 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <5420863E.1060608@tomh.org> <20140922212826.5048E216C3B@bikeshed.isc.org> <54210668.4050605@tomh.org> <20140923112746.EA16C216C3B@bikeshed.isc.org> <542991A8.4020908@tomh.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/p_YtJ4hB_FSM5EODoS13WSZ4fuk 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:21:51 -0000 Hi, seems ok to me too. On 09/29/2014 08:53 PM, Julien Laganier wrote: > Hi Tom, > > FWIW your proposal looks good to me. > > --julien > > On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson wrote: >> On 09/29/2014 09:20 AM, Tobias.Heer@Belden.com wrote: >>> >>> Hello, >>> >>> I'd like to confirm some of your statements. The thought was really to >>> show both options a) reuse of OGAs and b) what could happen if we need >>> more bits. However, the wording and the current set of IDs was chosen so >>> that it discourages the use of more IDs at the same time so the option >>> to take more bits from the OGA was really just a last resort. Nothing >>> anybody would really want. >>> >>> See my comments below. >>> >>> >>> >>> >>> Von: Francis Dupont >>> An: Tom Henderson , >>> Kopie: HIP , Francis Dupont , >>> julien.ietf@gmail.com >>> Datum: 26.09.2014 12:39 >>> Betreff: Re: [Hipsec] clarification on HIT Suite IDs >>> Gesendet von: "Hipsec" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Tom Henderson writes: >>> > 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. >>> >>> => yes, there is a long discussion in RFC 7343 about this tradeoff. >>> >>> > which implied to me that the HIT suite ID may in the future consume >>> more >>> > bits presently allocated to hash. >>> >>> => the fact the problem could exist doesn't mean it will exist... >>> >>> TH=> This was just to cover all options. It is not a desired or intended >>> action. >> >> >> There is discussion of this in the IANA considerations section; perhaps this >> could be modified as follows: >> >> Old text: >> >> If 16 Suite IDs prove insufficient and >> more HIT Suite IDs are needed concurrently, more bits can be used >> for the HIT Suite ID by using one HIT Suite ID (0) to indicate >> that more bits should be used. The HIT_SUITE_LIST parameter >> already supports 8-bit HIT Suite IDs, should longer IDs be needed. >> Possible extensions of the HIT Suite ID space to accommodate eight >> bits and new HIT Suite IDs are defined through IETF Review. >> >> New text: >> >> If 15 Suite IDs (the zero value is initially reserved) prove >> to be insufficient and >> more HIT Suite IDs are needed concurrently, more bits can be used >> for the HIT Suite ID by using one HIT Suite ID (0) to indicate >> that more bits should be used. The HIT_SUITE_LIST parameter >> already supports 8-bit HIT Suite IDs, should longer IDs be needed. >> However, RFC 7343 does not presently support such an extension, >> and the rollover approach described in Appendix E is suggested to >> be tried first. >> Possible extensions of the HIT Suite ID space to accommodate eight >> bits and new HIT Suite IDs are defined through IETF Review. >> >> >> >>> >>> > > 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? >>> >>> => one will need more than 15 HIT Suite-IDs -> >>> one will need more than 15 HIT Suite-IDs at the same time >>> >>> TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are >>> reasonably out of use. Appendix E describes this rollover. >> >> >> So for this proposal by Francis, we would change Appendix E text from: >> >> Since >> the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID >> 0 is reserved) to be used in parallel, phased-out HIT Suites must be >> reused at some point. In such a case, there will be a rollover of >> >> to: >> >> Since >> the 4-bit OGA field only permits 15 HIT Suites to be used at the >> same time (the HIT Suite with ID 0 is reserved), phased-out HIT >> Suites must be >> reused at some point. In such a case, there will be a rollover of >> >>> >>> > > => 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). >>> >>> => clearly the current plan is the first (reuse 4 bit values). >>> The second is just a provision in the case the first fails. >>> >>> TH=> Yes. I can confirm this. >>> >>> > 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. >>> >>> => perhaps it was considered as too optimistic? BTW I have no idea >>> about the future need in new values in the HIT_SUITE_ID / OGA space >>> (but does somebody already have one?) >>> >>> TH=> I am fine with not specifying the extension of the ID but to leave >>> 0 as reserved instead. >> >> >> Julien suggested that if we consider non-zero bits as an error at the >> receiver, it may facilitate use of the four non-zero high-order bits in >> future extensions. >> >> in 5.2.10, it says: >> >> The four >> lower-order bits are reserved and set to 0 and >> ignored by the receiver. >> >> The proposal would be to change this to: >> >> The four >> lower-order bits are reserved and set to 0 by >> the sender. The reception of an ID with >> the four lower-order bits not set to 0 should be >> considered as an error that MAY result in a >> NOTIFICATION of type UNSUPPORTED_HIT_SUITE. >> >> Any comments/concerns with this potential change? >> >>> >>> > 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. >>> >>> => it is a question for the hipsec mailing list (I subscribed to it >>> but from my personal e-mail). >>> >>> TH=> Moving the table to 5.2.10 is fine from my perspective. >> >> >> I tend to prefer this; I will work up a proposal for this. >> >> - Tom >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >