From gurtov@hiit.fi Wed Oct 12 00:01:44 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68121F8B03 for ; Wed, 12 Oct 2011 00:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZIO74o9rwfA for ; Wed, 12 Oct 2011 00:01:44 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id C6AFE21F8ACC for ; Wed, 12 Oct 2011 00:01:36 -0700 (PDT) Received: from [172.16.47.230] (unknown [78.186.117.167]) by argo.otaverkko.fi (Postfix) with ESMTP id E2FC425FB38 for ; Wed, 12 Oct 2011 10:01:34 +0300 (EEST) Message-ID: <4E953B23.3080906@hiit.fi> Date: Wed, 12 Oct 2011 10:00:51 +0300 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "hiprg@irtf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hiprg] tentative agenda for Taipei X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:01:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a draft agenda for Taipei HIPRG meeting, assuming we get a 2-hour slot. Please check your presentation titles! Andrei Gurtov/CWC. HIPRG Status update (15 m) Bob Moskowitz/Verizon. IEEE 802.15.HIP update (15m) Laszlo BOKOR/BME. HIP-Based Re-Authentication (15 m) Zoltan Faigl/BME. Delegation-based HIP mobility service in distributed/flat architectures (15 m) Xiaohu Xu/Huawei. Hierarchical HIP and proxies updates (15m) Jani Pellikka/CWC. HIP EAP AKA. (15 m) Tobias Heer/RWTH. WLAN roaming project update (15 m) Tapio Leva/Aalto. HIP deployment study final results (15 m) Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VOyMACgkQP7jp0uceFkSDbQCg3IWD3q/ZCeAJZzafhIrl6gTE pykAnjJL//Lf0Lze7o7T6QUK+ahvVFy0 =6ZdK -----END PGP SIGNATURE----- From thomas.r.henderson@boeing.com Thu Oct 20 16:58:10 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED3D21F8ACA for ; Thu, 20 Oct 2011 16:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkmwpHq2c1h7 for ; Thu, 20 Oct 2011 16:58:10 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3284121F88AB for ; Thu, 20 Oct 2011 16:58:10 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9KNw0SC013081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Oct 2011 16:58:07 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9KNvxQw018346 for ; Thu, 20 Oct 2011 16:58:00 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9KNvxTi018341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 20 Oct 2011 16:57:59 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 20 Oct 2011 16:57:59 -0700 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Thu, 20 Oct 2011 16:57:58 -0700 Thread-Topic: use of sha-1 in the DHT interface draft Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAHb2kgAAxGKRA= Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 23:58:11 -0000 We've received a comment during Gen-ART review of draft-irtf-hiprg-dht-04 t= hat merits list discussion. The comment, from Kathleen Moriarty, is below: > This is an experimental draft, building off of other experimental RFCs. > The IESG outlined a number of concerns at the start of RFC5201, at > least one of which is also present in this document. SHA-1 is no > longer a preferred algorithm and there is no algorithm agility in the > specification (it appears to be a field size limitation from previous > RFCs, but there is no explanation). This is not listed in the security > considerations either. If the IESG is still okay with experimental > documents proceeding with SHA-1 specified, this should be discussed in > the security considerations section at a minimum. It seems that the > service described could use another hash algorithm since the exchanges > are fully defined in this document. The usage of SHA-1 is as follows. 1) OpenDHT uses a SHA-1 hash in the "put" method as follows: secret_hash: SHA-1 hash of a secret that can be used to remove the put late= r (optional) Please see http://www.opendht.org/users-guide.html for more details. However, my understanding is that the DHT server does not enforce the use o= f SHA-1; modified clients (that are HIP-aware) could use SHA-256 truncated = to 160 bits. 2) SHA-1 is used to generate a 160-bit name (Section 4.1); any hashing func= tion would do here so long as the result fits into 160-bits. We are not re= lying on the security properties here. So, it seems like there are a few choices to proceed: - keep the draft as is, citing that OpenDHT interface prescribes SHA-1, and= that the other usage of SHA-1 is not trying to obtain any crypto propertie= s. However, the implication of this is we will need to add more text in th= e security section and elsewhere to defuse this "red flag" - keep the OpenDHT interface aspect at SHA-1 (to avoid changing the existin= g interface in this regard) but make the other name hash into SHA-256 (trun= cated) to avoid controversy on that point. - change both to SHA-256. Since we are already talking about clients modif= ied to support HIP, and it doesn't impact servers, this would just be one m= ore small change to clients. Any opinions on this? =20 There were a number of other comments that can be resolved in a draft updat= e that Jeff will post shortly. - Tom From mkomu@cs.hut.fi Thu Oct 20 23:15:48 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8311E8087 for ; Thu, 20 Oct 2011 23:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiD1ZoGCEeeI for ; Thu, 20 Oct 2011 23:15:46 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE7B11E807F for ; Thu, 20 Oct 2011 23:15:46 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1RH8OO-0002S2-7E for hiprg@irtf.org; Fri, 21 Oct 2011 09:15:44 +0300 Message-ID: <4EA10DFB.2070001@cs.hut.fi> Date: Fri, 21 Oct 2011 09:15:23 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: hiprg@irtf.org References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:15:48 -0000 Hi, On 21/10/11 02:57, Henderson, Thomas R wrote: > We've received a comment during Gen-ART review of draft-irtf-hiprg-dht-04 that merits list discussion. The comment, from Kathleen Moriarty, is below: > >> This is an experimental draft, building off of other experimental RFCs. >> The IESG outlined a number of concerns at the start of RFC5201, at >> least one of which is also present in this document. SHA-1 is no >> longer a preferred algorithm and there is no algorithm agility in the >> specification (it appears to be a field size limitation from previous >> RFCs, but there is no explanation). This is not listed in the security >> considerations either. If the IESG is still okay with experimental >> documents proceeding with SHA-1 specified, this should be discussed in >> the security considerations section at a minimum. It seems that the >> service described could use another hash algorithm since the exchanges >> are fully defined in this document. > > The usage of SHA-1 is as follows. > > 1) OpenDHT uses a SHA-1 hash in the "put" method as follows: > secret_hash: SHA-1 hash of a secret that can be used to remove the put later (optional) > > Please see http://www.opendht.org/users-guide.html for more details. > > However, my understanding is that the DHT server does not enforce the use of SHA-1; modified clients (that are HIP-aware) could use SHA-256 truncated to 160 bits. > > 2) SHA-1 is used to generate a 160-bit name (Section 4.1); any hashing function would do here so long as the result fits into 160-bits. We are not relying on the security properties here. > > So, it seems like there are a few choices to proceed: > > - keep the draft as is, citing that OpenDHT interface prescribes SHA-1, and that the other usage of SHA-1 is not trying to obtain any crypto properties. However, the implication of this is we will need to add more text in the security section and elsewhere to defuse this "red flag" > > - keep the OpenDHT interface aspect at SHA-1 (to avoid changing the existing interface in this regard) but make the other name hash into SHA-256 (truncated) to avoid controversy on that point. > > - change both to SHA-256. Since we are already talking about clients modified to support HIP, and it doesn't impact servers, this would just be one more small change to clients. > > Any opinions on this? > > There were a number of other comments that can be resolved in a draft update that Jeff will post shortly. if crypto agility is not an option, I 'd suggest to change both to SHA-256. From heer@informatik.rwth-aachen.de Fri Oct 21 04:59:48 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A46021F8BD5 for ; Fri, 21 Oct 2011 04:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eixsqALWx6tK for ; Fri, 21 Oct 2011 04:59:47 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2E16121F8BB8 for ; Fri, 21 Oct 2011 04:59:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LTE006FQZZL0QI0@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 13:59:45 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.69,385,1315173600"; d="scan'208";a="66943961" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 21 Oct 2011 13:59:45 +0200 Received: from [137.226.12.157] ([unknown] [137.226.12.157]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LTE00L2OZZLAVB0@relay-auth-2.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 13:59:45 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> Date: Fri, 21 Oct 2011 13:59:45 +0200 Message-id: <2145AC2B-21D7-4535-98C8-916A3447201A@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1084) Cc: "hiprg@irtf.org" Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:59:48 -0000 Hello, Am 21.10.2011 um 01:57 schrieb Henderson, Thomas R: > We've received a comment during Gen-ART review of draft-irtf-hiprg-dht-04 that merits list discussion. The comment, from Kathleen Moriarty, is below: > [...] > - change both to SHA-256. Since we are already talking about clients modified to support HIP, and it doesn't impact servers, this would just be one more small change to clients. > I would prefer this option. It does not seem to break the interface and legacy compatibility does not seem an issue. However, I am not sure about the practical security benefits of truncated SHA-256 compared to SHA-1. Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF From samu.varjonen@helsinki.fi Fri Oct 21 06:34:08 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B7521F8C45 for ; Fri, 21 Oct 2011 06:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7DkATvvgGS3 for ; Fri, 21 Oct 2011 06:34:07 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24421F8B4E for ; Fri, 21 Oct 2011 06:34:06 -0700 (PDT) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id 1DAF525FCB7 for ; Fri, 21 Oct 2011 16:34:04 +0300 (EEST) Message-ID: <4EA174CB.8000409@helsinki.fi> Date: Fri, 21 Oct 2011 16:34:03 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: hiprg@irtf.org References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <2145AC2B-21D7-4535-98C8-916A3447201A@cs.rwth-aachen.de> In-Reply-To: <2145AC2B-21D7-4535-98C8-916A3447201A@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:34:08 -0000 On 21/10/11 14:59, Tobias Heer wrote: > Hello, > > Am 21.10.2011 um 01:57 schrieb Henderson, Thomas R: > >> We've received a comment during Gen-ART review of draft-irtf-hiprg-dht-04 that merits list discussion. The comment, from Kathleen Moriarty, is below: >> > [...] >> - change both to SHA-256. Since we are already talking about clients modified to support HIP, and it doesn't impact servers, this would just be one more small change to clients. >> > I would prefer this option. It does not seem to break the interface and legacy compatibility does not seem an issue. However, I am not sure about the practical security benefits of truncated SHA-256 compared to SHA-1. > +1 > Best regards, > > Tobias > From jeffrey.m.ahrenholz@boeing.com Fri Oct 21 08:00:02 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6799721F8C1E for ; Fri, 21 Oct 2011 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rrU1WtvrLA9 for ; Fri, 21 Oct 2011 08:00:01 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7721F8C22 for ; Fri, 21 Oct 2011 08:00:01 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9LExtan022108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Oct 2011 07:59:58 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9LExtsF008413 for ; Fri, 21 Oct 2011 07:59:55 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9LExtcv008408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 21 Oct 2011 07:59:55 -0700 (PDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 21 Oct 2011 07:59:55 -0700 From: "Ahrenholz, Jeffrey M" To: "Henderson, Thomas R" , "hiprg@irtf.org" Date: Fri, 21 Oct 2011 07:59:57 -0700 Thread-Topic: use of sha-1 in the DHT interface draft Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAHb2kgAAxGKRAAHo84kA== Message-ID: References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:00:02 -0000 > However, my understanding is that the DHT server does not enforce the > use of SHA-1; modified clients (that are HIP-aware) could use SHA-256 > truncated to 160 bits. The DHT server does use SHA-1 internally to process removes. If the client = uses another hash function, the secret given in the DHT remove will not mat= ch the SHA-1 hash used in the put. The draft does not currently require a modified OpenDHT/Bamboo server. It s= tates in sections 3 and 7 that the server MAY/SHOULD be modified for signat= ure and host ID verification (it looks like the "MAY" in section 3 should b= e changed to "SHOULD".) Use of another hash algorithm would require furthe= r server modifications (and specifying an interface that deviates from Open= DHT.) > - keep the draft as is, citing that OpenDHT interface prescribes SHA-1, > and that the other usage of SHA-1 is not trying to obtain any crypto > properties. However, the implication of this is we will need to add > more text in the security section and elsewhere to defuse this "red > flag" I would prefer the above option. The security considerations section can in= clude text about deviating from the OpenDHT interface in order to support o= ther hash functions. The original intent of the draft was to re-use the fre= ely-available OpenDHT interface in an interoperable fashion. -Jeff From jeffrey.m.ahrenholz@boeing.com Fri Oct 21 08:10:38 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B191F0C68; Fri, 21 Oct 2011 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja8qSaWBrGpB; Fri, 21 Oct 2011 08:10:37 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 924FA1F0C62; Fri, 21 Oct 2011 08:10:37 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9LF9xPq012936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2011 10:10:00 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9LF9xFK023841; Fri, 21 Oct 2011 08:09:59 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9LF9wdm023828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 21 Oct 2011 08:09:59 -0700 (PDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 21 Oct 2011 08:09:58 -0700 From: "Ahrenholz, Jeffrey M" To: "kathleen.moriarty@emc.com" , "gen-art@ietf.org" , "hiprg@irtf.org" Date: Fri, 21 Oct 2011 08:10:01 -0700 Thread-Topic: Gen-ART review for draft-irtf-hiprg-dht-04 Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAMOigQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-irtf-hiprg-dht.all@tools.ietf.org" , "ietf@ietf.org" Subject: Re: [hiprg] Gen-ART review for draft-irtf-hiprg-dht-04 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:10:38 -0000 Thanks for reviewing this DHT draft. Comments are inline below. I plan to post an updated draft once we work out the SHA-1 issues on the hi= prg list. -Jeff > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Thursday, October 20, 2011 7:11 AM > To: gen-art@ietf.org; Ahrenholz, Jeffrey M > Cc: ietf@ietf.org; draft-irtf-hiprg-dht.all@tools.ietf.org > Subject: Gen-ART review for draft-irtf-hiprg-dht-04 >=20 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-irtf-hiprg-dht-04 > Reviewer: Kathleen Moriarty > Review Date: October 20, 2011 > IETF LC End Date: 11/1/11 > IESG Telechat date: (if known) >=20 > Summary: This draft requires further review. There are just a few > grammar nits listed below, but the use of SHA-1 should be updated or > noted as a concern. >=20 > This is an experimental draft, building off of other experimental RFCs. > The IESG outlined a number of concerns at the start of RFC5201, at > least one of which is also present in this document. SHA-1 is no > longer a preferred algorithm and there is no algorithm agility in the > specification (it appears to be a field size limitation from previous > RFCs, but there is no explanation). This is not listed in the security > considerations either. If the IESG is still okay with experimental > documents proceeding with SHA-1 specified, this should be discussed in > the security considerations section at a minimum. It seems that the > service described could use another hash algorithm since the exchanges > are fully defined in this document. SHA-1 is prescribed by the OpenDHT interface that this draft aims to suppor= t. >=20 > If the algorithm cannot be updated, the description of the design in > the abstract should be updated as HIP is not designed with the security > features described in the following sentences. > "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." >=20 > This could be a result of RFC5201 having a MUST statement for the use > of SHA-1. The earlier document, RFC4423 specifies a hash is to be used > and at the time it was written, SHA-1 was the NIST recommendation > (2003). >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: > Abstract: Change: This document specifies a common interface for using > HIP with a > To: "This document specifies a common interface for using Host Identity > Protocol (HIP) with a" > The Introduction uses the spelled out acronym without putting (HIP) > after it if you want to define it here as well. Fixed. > Introduction: 3rd sentence, add a comma: > Change from: "These keys are hashed and prefixed > to form Host Identity Tags (HITs) which appear as large random > numbers." > To: "These keys are hashed and prefixed > to form Host Identity Tags (HITs), which appear as large random > numbers." Fixed. >=20 > Section 2: Is there a reason why the hash value is limited to using > SHA-1? This should be a choice for algorithm agility if possible. Yes, SHA-1 is prescribed by OpenDHT; it was not a choice made for this prot= ocol. This is open for discussion on the hiprg list. =20 > Section3, paragraph 6: Consider breaking this into two sentences: > "The host SHOULD > retain the last Update ID value it used for each HIT across reboots, > or perform a self lookup in the DHT, since that number may be > retained in the DHT records and will determine the preferred address > used by peers." Fixed. > Section 4, paragraph 4: Consider changing the following sentence > (joining two thoughts not three) and 'address publish' does not read > quite right: > From: "The ttl_sec field used with address publish includes the time- > to- > live, the number of seconds for which the entry will be stored by > the > DHT, which SHOULD be set to the number of seconds remaining in the > address lifetime." > To: "The ttl_sec field used with the address publish command includes > the time-to- > Live and the number of seconds for which the entry will be stored by > the > DHT, which SHOULD be set to the number of seconds remaining in the > address lifetime." Fixed. Also reworded "address publish." =20 > Section 7: Security Considerations > If there is some reason why you can't use anything stronger than SHA-1 > for a hash, this should also be listed as a security consideration. I > don't think the IETF is putting through documents that use SHA-1 > anymore as standards track. >=20 SHA-1 is used in two ways: 1) put / remove operation 2) reduce the size of the name string for name lookups Usage #1 is defined by the OpenDHT interface. Usage #2 is not relying on cr= ypto properties of the hash, just reducing the string length to fit in 160 = bits. From thomas.r.henderson@boeing.com Fri Oct 21 08:33:30 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4897F1F0C8B for ; Fri, 21 Oct 2011 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sPFhqTSocS4 for ; Fri, 21 Oct 2011 08:33:29 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id B80001F0C6F for ; Fri, 21 Oct 2011 08:33:29 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9LFXSeV014051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Oct 2011 08:33:29 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9LFXR9w001330 for ; Fri, 21 Oct 2011 10:33:27 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9LFXRaQ001305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 21 Oct 2011 10:33:27 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 21 Oct 2011 08:33:26 -0700 From: "Henderson, Thomas R" To: "Ahrenholz, Jeffrey M" , "hiprg@irtf.org" Date: Fri, 21 Oct 2011 08:33:26 -0700 Thread-Topic: use of sha-1 in the DHT interface draft Thread-Index: AcyPMhu12S232/FYTZeFIp5WqSol+QAHb2kgAAxGKRAAHo84kAACxTFA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:33:30 -0000 > -----Original Message----- > From: Ahrenholz, Jeffrey M > Sent: Friday, October 21, 2011 8:00 AM > To: Henderson, Thomas R; hiprg@irtf.org > Subject: RE: use of sha-1 in the DHT interface draft >=20 > > However, my understanding is that the DHT server does not enforce the > > use of SHA-1; modified clients (that are HIP-aware) could use SHA-256 > > truncated to 160 bits. >=20 > The DHT server does use SHA-1 internally to process removes. If the > client uses another hash function, the secret given in the DHT remove > will not match the SHA-1 hash used in the put. I did not catch that detail since it is not very clear from the API documen= t, but it makes more sense that it operates that way. >=20 > The draft does not currently require a modified OpenDHT/Bamboo server. > It states in sections 3 and 7 that the server MAY/SHOULD be modified > for signature and host ID verification (it looks like the "MAY" in > section 3 should be changed to "SHOULD".) Use of another hash > algorithm would require further server modifications (and specifying an > interface that deviates from OpenDHT.) >=20 > > - keep the draft as is, citing that OpenDHT interface prescribes SHA- > 1, > > and that the other usage of SHA-1 is not trying to obtain any crypto > > properties. However, the implication of this is we will need to add > > more text in the security section and elsewhere to defuse this "red > > flag" >=20 > I would prefer the above option. The security considerations section > can include text about deviating from the OpenDHT interface in order to > support other hash functions. The original intent of the draft was to > re-use the freely-available OpenDHT interface in an interoperable > fashion. >=20 In light of the above, I would lean towards your recommendation as well. =20 - Tom From heer@informatik.rwth-aachen.de Fri Oct 21 09:04:58 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D848D1F0C84 for ; Fri, 21 Oct 2011 09:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-Ch-SnON6hw for ; Fri, 21 Oct 2011 09:04:58 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id E7B511F0C76 for ; Fri, 21 Oct 2011 09:04:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LTF001N1BC24IK0@mta-2.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 18:04:50 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.69,386,1315173600"; d="scan'208";a="66968420" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 21 Oct 2011 18:04:51 +0200 Received: from umic-i4-137-226-45-203.nn.rwth-aachen.de ([unknown] [137.226.45.203]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LTF00D89BC2JR70@relay-auth-2.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Fri, 21 Oct 2011 18:04:50 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com> Date: Fri, 21 Oct 2011 18:04:51 +0200 Message-id: <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1084) Cc: "hiprg@irtf.org" Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:04:58 -0000 Am 21.10.2011 um 17:33 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: Ahrenholz, Jeffrey M >> Sent: Friday, October 21, 2011 8:00 AM >> To: Henderson, Thomas R; hiprg@irtf.org >> Subject: RE: use of sha-1 in the DHT interface draft >> >>> However, my understanding is that the DHT server does not enforce the >>> use of SHA-1; modified clients (that are HIP-aware) could use SHA-256 >>> truncated to 160 bits. >> >> The DHT server does use SHA-1 internally to process removes. If the >> client uses another hash function, the secret given in the DHT remove >> will not match the SHA-1 hash used in the put. > > I did not catch that detail since it is not very clear from the API document, but it makes more sense that it operates that way. > >> >> The draft does not currently require a modified OpenDHT/Bamboo server. >> It states in sections 3 and 7 that the server MAY/SHOULD be modified >> for signature and host ID verification (it looks like the "MAY" in >> section 3 should be changed to "SHOULD".) Use of another hash >> algorithm would require further server modifications (and specifying an >> interface that deviates from OpenDHT.) >> >>> - keep the draft as is, citing that OpenDHT interface prescribes SHA- >> 1, >>> and that the other usage of SHA-1 is not trying to obtain any crypto >>> properties. However, the implication of this is we will need to add >>> more text in the security section and elsewhere to defuse this "red >>> flag" >> >> I would prefer the above option. The security considerations section >> can include text about deviating from the OpenDHT interface in order to >> support other hash functions. The original intent of the draft was to >> re-use the freely-available OpenDHT interface in an interoperable >> fashion. >> > > In light of the above, I would lean towards your recommendation as well. > +1 Same here. If compatibility is an issue, it outweighs the other reasons. Having an API that is incompatible to the system makes little sense. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF From L.Wood@surrey.ac.uk Fri Oct 21 09:24:57 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173A1F0C81 for ; Fri, 21 Oct 2011 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brsy74icIb9r for ; Fri, 21 Oct 2011 09:24:54 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A61F0C8B for ; Fri, 21 Oct 2011 09:24:54 -0700 (PDT) Received: from [195.245.230.131:26525] by server-1.bemta-3.messagelabs.com id 1D/E5-26599-4DC91AE4; Fri, 21 Oct 2011 16:24:52 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-2.tower-78.messagelabs.com!1319214291!89762735!1 X-Originating-IP: [131.227.200.39] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11520 invoked from network); 21 Oct 2011 16:24:52 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-2.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2011 16:24:52 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.171]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 21 Oct 2011 17:24:51 +0100 From: To: , Date: Fri, 21 Oct 2011 17:22:23 +0100 Thread-Topic: [hiprg] use of sha-1 in the DHT interface draft Thread-Index: AcyPuOLfR3PJdI5WQiOZoNNMOWcD8AAT36Jw Message-ID: References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <4EA10DFB.2070001@cs.hut.fi> In-Reply-To: <4EA10DFB.2070001@cs.hut.fi> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: wes@mti-systems.com Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:24:57 -0000 I have a broader comment on this, having been here before. I ran into a similar problem when using MD5 in a protocol in a non-security context for purely error-checking purposes, and endured much criticism from self-professed security types for even considering or mentioning MD5 at all. That experience from 2007 onward eventually fed into some carefully-worded text in: RFC 6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms March 2011 but we're still specifying MD5 use as an optional checksum, because it's lightweight and useful for rejecting errors in file transfers and supporting the end-to-end principle. For SHA-1, the equivalent document is: RFC 6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms March 2011 my thoughts are: - text explaining use of SHA-1 in a none-security context will need to mention RFC 6194, or kick off an update to RFC 6194. - since any crypto/hash algorithm is going to be subject to attacks, flexibility in handling a variety of algorithm options is key, as soon SHA-256 will Just Not Be Good Enough. If you want wide deployment, you don't want a full protocol redesign every couple of years... - a fixed-length field is indeed a bit of a design problem. - mentioning MD5 or SHA-1 should not immediately be a red flag; context is important. - SHA-1 is the new MD5. - SHA-256 will be the new SHA-1, which is to say the new new MD5. - Since it's 160 bits, hey, you could specify MD5 too! At this point, probably as useful. - Security is fashion. Red is the new black. Lloyd Wood http://saratoga.sf.net/ > -----Original Message----- > From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org]=20 > On Behalf Of Miika Komu > Sent: 21 October 2011 07:15 > To: hiprg@irtf.org > Subject: Re: [hiprg] use of sha-1 in the DHT interface draft >=20 > Hi, >=20 > On 21/10/11 02:57, Henderson, Thomas R wrote: > > We've received a comment during Gen-ART review of=20 > draft-irtf-hiprg-dht-04 that merits list discussion. The=20 > comment, from Kathleen Moriarty, is below: > > > >> This is an experimental draft, building off of other=20 > experimental RFCs. > >> The IESG outlined a number of concerns at the start of RFC5201, at=20 > >> least one of which is also present in this document. SHA-1 is no=20 > >> longer a preferred algorithm and there is no algorithm=20 > agility in the=20 > >> specification (it appears to be a field size limitation=20 > from previous=20 > >> RFCs, but there is no explanation). This is not listed in the=20 > >> security considerations either. If the IESG is still okay with=20 > >> experimental documents proceeding with SHA-1 specified,=20 > this should=20 > >> be discussed in the security considerations section at a=20 > minimum. It=20 > >> seems that the service described could use another hash algorithm=20 > >> since the exchanges are fully defined in this document. > > > > The usage of SHA-1 is as follows. > > > > 1) OpenDHT uses a SHA-1 hash in the "put" method as follows: > > secret_hash: SHA-1 hash of a secret that can be used to=20 > remove the put=20 > > later (optional) > > > > Please see http://www.opendht.org/users-guide.html for more details. > > > > However, my understanding is that the DHT server does not=20 > enforce the use of SHA-1; modified clients (that are=20 > HIP-aware) could use SHA-256 truncated to 160 bits. > > > > 2) SHA-1 is used to generate a 160-bit name (Section 4.1);=20 > any hashing function would do here so long as the result fits=20 > into 160-bits. We are not relying on the security properties here. > > > > So, it seems like there are a few choices to proceed: > > > > - keep the draft as is, citing that OpenDHT interface=20 > prescribes SHA-1, and that the other usage of SHA-1 is not=20 > trying to obtain any crypto properties. However, the=20 > implication of this is we will need to add more text in the=20 > security section and elsewhere to defuse this "red flag" > > > > - keep the OpenDHT interface aspect at SHA-1 (to avoid=20 > changing the existing interface in this regard) but make the=20 > other name hash into SHA-256 (truncated) to avoid controversy=20 > on that point. > > > > - change both to SHA-256. Since we are already talking=20 > about clients modified to support HIP, and it doesn't impact=20 > servers, this would just be one more small change to clients. > > > > Any opinions on this? > > > > There were a number of other comments that can be resolved=20 > in a draft update that Jeff will post shortly. >=20 > if crypto agility is not an option, I 'd suggest to change=20 > both to SHA-256. > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg > = From mkomu@cs.hut.fi Sat Oct 22 00:18:33 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2AE11E80B7 for ; Sat, 22 Oct 2011 00:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snEB+UrOM32D for ; Sat, 22 Oct 2011 00:18:33 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id C48F411E80A2 for ; Sat, 22 Oct 2011 00:18:32 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1RHVqg-0002RK-8d for hiprg@irtf.org; Sat, 22 Oct 2011 10:18:30 +0300 Message-ID: <4EA26E28.7020808@cs.hut.fi> Date: Sat, 22 Oct 2011 10:18:00 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: hiprg@irtf.org References: <7CC566635CFE364D87DC5803D4712A6C4CF18DF866@XCH-NW-10V.nw.nos.boeing.com> <7CC566635CFE364D87DC5803D4712A6C4CF18DF86B@XCH-NW-10V.nw.nos.boeing.com> <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de> In-Reply-To: <727A9046-EED3-46C8-BC48-E127BEE5BA41@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hiprg] use of sha-1 in the DHT interface draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 07:18:33 -0000 Hi, On 21/10/11 19:04, Tobias Heer wrote: >>> The draft does not currently require a modified OpenDHT/Bamboo server. >>> >> It states in sections 3 and 7 that the server MAY/SHOULD be modified >>> >> for signature and host ID verification (it looks like the "MAY" in >>> >> section 3 should be changed to "SHOULD".) Use of another hash >>> >> algorithm would require further server modifications (and specifying an >>> >> interface that deviates from OpenDHT.) >>> >> >>>> >>> - keep the draft as is, citing that OpenDHT interface prescribes SHA- >>> >> 1, >>>> >>> and that the other usage of SHA-1 is not trying to obtain any crypto >>>> >>> properties. However, the implication of this is we will need to add >>>> >>> more text in the security section and elsewhere to defuse this "red >>>> >>> flag" >>> >> >>> >> I would prefer the above option. The security considerations section >>> >> can include text about deviating from the OpenDHT interface in order to >>> >> support other hash functions. The original intent of the draft was to >>> >> re-use the freely-available OpenDHT interface in an interoperable >>> >> fashion. >>> >> >> > >> > In light of the above, I would lean towards your recommendation as well. >> > > +1 > Same here. If compatibility is an issue, it outweighs the other reasons. Having an API that is incompatible to the system makes little sense. +1 (needs to be documented well in Security Considerations as mentioned by Lloyd Wood) From heer@informatik.rwth-aachen.de Mon Oct 31 03:00:31 2011 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2C421F8D61 for ; Mon, 31 Oct 2011 03:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzdSEhd67D3M for ; Mon, 31 Oct 2011 03:00:30 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5B95321F8D4D for ; Mon, 31 Oct 2011 03:00:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LTX00H4RD4T3H90@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Mon, 31 Oct 2011 11:00:29 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.69,430,1315173600"; d="scan'208";a="145052216" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 31 Oct 2011 11:00:29 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LTX005BED4S7240@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Mon, 31 Oct 2011 11:00:28 +0100 (CET) From: Tobias Heer Date: Mon, 31 Oct 2011 11:00:28 +0100 References: <20111031095725.2843.73146.idtracker@ietfa.amsl.com> To: hiprg@irtf.org Message-id: <1C0681EB-E7F6-45A5-8280-76B348F4FEF9@cs.rwth-aachen.de> X-Mailer: Apple Mail (2.1084) Subject: [hiprg] Fwd: New Version Notification for draft-heer-hip-middle-auth-04.txt X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:00:31 -0000 Hi, we just submitted a new version of draft-heer-hip-middle-auth. It now includes an improved handling of multiple middlebox nonces and supports authentication of CLOSE messages. The new version is available here: http://www.ietf.org/id/draft-heer-hip-middle-auth-04.txt Feedback and comments are very much appreciated. Best regards, Tobias Anfang der weitergeleiteten E-Mail: > Von: internet-drafts@ietf.org > Datum: 31. Oktober 2011 10:57:25 MEZ > An: heer@cs.rwth-aachen.de > Kopie: hummen@cs.rwth-aachen.de, heer@cs.rwth-aachen.de, miika@iki.fi > Betreff: New Version Notification for draft-heer-hip-middle-auth-04.txt > > A new version of I-D, draft-heer-hip-middle-auth-04.txt has been successfully submitted by Tobias Heer and posted to the IETF repository. > > Filename: draft-heer-hip-middle-auth > Revision: 04 > Title: End-Host Authentication for HIP Middleboxes > Creation date: 2011-10-28 > WG ID: Individual Submission > Number of pages: 24 > > Abstract: > The Host Identity Protocol [RFC5201] is a signaling protocol for > secure communication, mobility, and multihoming that introduces a > cryptographic namespace. This document specifies an extension for > HIP that enables middleboxes to unambiguously verify the identities > of hosts that communicate across them. This extension allows > middleboxes to verify the liveness and freshness of a HIP association > and, thus, to secure access control in middleboxes. > > > > > > The IETF Secretariat -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF