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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 08 July 2014 17:59 UTC

Return-Path: <mcr@sandelman.ca>
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 DA3F61A035E; Tue, 8 Jul 2014 10:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.343
X-Spam-Level:
X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, 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 YpwZBvw1Gwi3; Tue, 8 Jul 2014 10:59:57 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A981A02EF; Tue, 8 Jul 2014 10:59:57 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FE5820028; Tue, 8 Jul 2014 14:00:45 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1D07E63B0E; Tue, 8 Jul 2014 13:59:54 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0908163B09; Tue, 8 Jul 2014 13:59:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <53BBC8DE.1010006@cs.tcd.ie>
References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 08 Jul 2014 13:59:54 -0400
Message-ID: <8171.1404842394@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/khLs-rIarM1q7wvePnOE2r5VnhI
X-Mailman-Approved-At: Sun, 20 Jul 2014 05:30:23 -0700
Cc: hipsec@ietf.org, saag@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, 08 Jul 2014 17:59:59 -0000

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 =-