Re: [Hipsec] NULL encryption mode in RFC 5202-bis
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 08 July 2014 10:33 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 BE8D91B2A68; Tue, 8 Jul 2014 03:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 y-rlfakWGjrG; Tue, 8 Jul 2014 03:33:05 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EBDEE1B27E7; Tue, 8 Jul 2014 03:33:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BB1ABE10; Tue, 8 Jul 2014 11:33:04 +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 fKIuCWuqcdXj; Tue, 8 Jul 2014 11:33:03 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.46.22.239]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2B65BE0F; Tue, 8 Jul 2014 11:33:02 +0100 (IST)
Message-ID: <53BBC8DE.1010006@cs.tcd.ie>
Date: Tue, 08 Jul 2014 11:33:02 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tom Henderson <tomh@tomh.org>, hipsec@ietf.org, saag@ietf.org
References: <53BB798A.3080101@tomh.org>
In-Reply-To: <53BB798A.3080101@tomh.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1-aP63e_x_ajjodIufF5YdunMkg
Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis
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: Tue, 08 Jul 2014 10:33:08 -0000
Thanks Tom, On 08/07/14 05:54, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. It was also > stated in previous drafts that this mode supports debugging. > > Null encryption was also specified as a MUST to implement in RFC5202 and > dates back to earlier versions of the HIP base draft (to 2003: > http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3) Right. I guess my discuss has a generic part and a hip specific part. Generic: is it still considered a good plan to have null confidentiality suites such as these? Or for those to be Mandatory-To-Implement (MTI)? That clearly was the generic consensus as we have these in a number of protocols. The new reasons to move from that I think are: 1) we no longer need this for debugging purposes really since libraries and dev tools have moved on and are better now, and we specifically no longer need these for protocols that are no longer new, 2) BCP188 could be considered to argue against having these as they could be misused. (All the old arguments of course do still apply, but I think the above are the ones that are new.) So is that enough to shift the consensus away from having these or having them be MTI? Specific: is there anything specific about hip that would trump the general point above? Note that there could be, regardless of where consensus lies on the generic question. FWIW, my own answers for these are that its probably a better plan today to not have (or make MTI) these null confidentiality ciphersuites, and I don't know that hip would have any specific reason to diverge from that. But I'd really like to see if there is a modified consensus on this or not. (To be clear, if there's not a new consensus then the current one would seem to still apply here and I'll clear my discuss.) Cheers, S. > > - Tom
- [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Miika Komu
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Henry B Hotz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Edward Lopez
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon