[Hipsec] RFC5201-bis and RFC5202-bis status
Tom Henderson <tomh@tomh.org> Fri, 05 September 2014 18:46 UTC
Return-Path: <tomh@tomh.org>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20A41A0167 for <hipsec@ietfa.amsl.com>; 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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietf.org>; 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 <tomh@tomh.org>) 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 <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: HIP <hipsec@ietf.org>
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 <barryleiba@computer.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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
- [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-1… internet-drafts
- [Hipsec] RFC5201-bis and RFC5202-bis status Tom Henderson
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Ted Lemon
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Tom Henderson
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Tom Taylor
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Gonzalo Camarillo
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Tom Henderson
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Jari Arkko
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Jari Arkko
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Miika Komu
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Tom Henderson
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Ted Lemon
- Re: [Hipsec] RFC5201-bis and RFC5202-bis status Gonzalo Camarillo