Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
Robert Moskowitz <rgm@htt-consult.com> Tue, 22 July 2014 14:29 UTC
Return-Path: <rgm@htt-consult.com>
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 D03751B291A; Tue, 22 Jul 2014 07:29:11 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 52hUvBdYxGpu; Tue, 22 Jul 2014 07:29:09 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB11B2929; Tue, 22 Jul 2014 07:29:08 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E739262A80; Tue, 22 Jul 2014 14:29:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIq7LS6wKR1D; Tue, 22 Jul 2014 10:28:56 -0400 (EDT)
Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 36FD462A5A; Tue, 22 Jul 2014 10:28:56 -0400 (EDT)
Message-ID: <53CE7526.3020702@htt-consult.com>
Date: Tue, 22 Jul 2014 10:28:54 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Henry B Hotz <hbhotz@oxy.edu>, Paul Lambert <paul@marvell.com>
References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu>
In-Reply-To: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu>
Content-Type: multipart/alternative; boundary="------------080207070708030309000503"
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/kpaLIMae1IrjwJXsl_ylOfJny8U
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "saag@ietf.org" <saag@ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] [saag] 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, 22 Jul 2014 14:29:12 -0000
On 07/21/2014 08:51 PM, Henry B Hotz wrote: > The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability. In this regard, I have a hard time distinguishing between NULL with HMAC-SHA256 and CMAC or GMAC. With this (secure communications) context NULL means no privacy but yes authenticity. > > Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no". > > My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST. > > > On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote: > >> NULL may be useful to some, but should NOT be mandated (should rather than must). >> It's another knob that could be set incorrectly and bypass the encryption. Not all products will want or need NULL. >> >> >> Paul >> >> ]-----Original Message----- >> ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael >> ]Richardson >> ]Sent: Tuesday, July 08, 2014 11:00 AM >> ]To: Stephen Farrell >> ]Cc: hipsec@ietf.org; saag@ietf.org >> ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis >> ] >> ] >> ]Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >> ] > 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 >> ] >> ]There are an incredible number of systems (Linux with stock-in-kernel >> ]NETKEY IPsec for instance), where it is impossible or very very >> ]difficult to get a packet capture of the traffic after decryption, but >> ]before it goes up the protocol stack. >> ] >> ]On such systems, if you have a problem in the field with a protocol that >> ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how >> ]it works, and it appears to with without ESP, then the lack of debugging >> ]means that you turn off all security. >> ] >> ]ESP-authenticated-with-NULL-encryption is debuggable in the field. >> ]Not having it, means turning off ESP; and if the problem is in the link >> ]between the ESP layer and the upper layer, then... >> ] >> ]-- >> ]Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= >> ]IPv6 IoT consulting =- >> ] >> ] >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > Personal email. hbhotz@oxy.edu > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec
- [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