Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis

Edward Lopez <elopez@fortinet.com> Tue, 22 July 2014 15:28 UTC

Return-Path: <elopez@fortinet.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 9D8FB1B29A3; Tue, 22 Jul 2014 08:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.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 RthEHcEJDWuz; Tue, 22 Jul 2014 08:28:54 -0700 (PDT)
Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F091B29AE; Tue, 22 Jul 2014 08:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=7VA32uHBSK3Lyt7BcuspCQD1H/xziBCBSZRp6txjSqM=; b=IlkE264z6U0FeKOY0T2Wk3JT45QidOkYuQbjCwv4DG2AmU4FSLSc9AMmqRuIyz9eajExFnCcB4ORvZoNcz0/fynTZlfosEseGNG/Vzi9HsGuq7fHwmYn8/VdLy7H0anmak5+Txtmj2MuMPkFCqkjy35CkCnxLiBUjNwJmjG/HUQKbqFbPxV4fYQEyEtkS3axcdVt3Ay5J19P0cNf5+/Fp4GLspg0TeET0c3mK/h4same3j6z5WnsiHFPBmS02Ml4Ry6jWK3PYMBQyg8KodmLHtjSlSxZBQxbYHL24iA7w7VLbeBxmA3W99Rz+zg1fXV7n7QLP5e7DZzlp+6qbsYVRg==
From: Edward Lopez <elopez@fortinet.com>
To: "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis
Thread-Index: AQHPpT+FosFAE5Hfxk6vedbZfWESXpuruOeAgAD1fIA=
Date: Tue, 22 Jul 2014 15:28:52 +0000
Message-ID: <3DF58EBF-7AFA-4174-9306-2F38427C0047@fortinet.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.165.97]
Content-Type: multipart/alternative; boundary="_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/xkFcRVlyp1l6CkzcbxiloSgCKN8
X-Mailman-Approved-At: Tue, 22 Jul 2014 10:17:43 -0700
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Henry B Hotz <hbhotz@oxy.edu>, "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 15:28:56 -0000

In my view, the underlying question is concerned with the value of a common encryption algorithm across all implementations of ESP, NULL or otherwise.  In my experience, the existence of mandatory common denominators in standards results in improved interoperability between implementations.  In the particular case of ESP, I agree that virtually no one would implement IPSec using NULL encryption, and we heavily rely on de-facto common use of US NIST-approved protocols (DES, 3DES, AES) for interoperability today.

My point is that by removing the MUST requirement for NULL encryption, should be consider the idea that we are substituting a stated common encryption protocol for a set of implied ones.  We will also be eliminating implementation choices over time for those requiring NULL encryption.

I’m not strongly advocating keeping the MUST, and would likely be ok to replace it with SHOULD.  But I did want to state that this surrendering of an mandated algorithm, and its consequences relative to maintaining interoperability, is a factor that I considered.

Ed



On Jul 21, 2014, at 8:51 PM, Henry B Hotz <hbhotz@oxy.edu<mailto:hbhotz@oxy.edu>> wrote:

The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

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<mailto: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<mailto:bounces@ietf.org>] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: hipsec@ietf.org<mailto:hipsec@ietf.org>; saag@ietf.org<mailto:saag@ietf.org>
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto: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<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

_______________________________________________
saag mailing list
saag@ietf.org<mailto:saag@ietf.org>
https://www.ietf.org/mailman/listinfo/saag

Personal email.  hbhotz@oxy.edu<mailto:hbhotz@oxy.edu>



_______________________________________________
saag mailing list
saag@ietf.org<mailto:saag@ietf.org>
https://www.ietf.org/mailman/listinfo/saag



***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***