Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ???

Paul Wouters <paul@cypherpunks.ca> Mon, 09 December 2013 18:50 UTC

Return-Path: <paul@cypherpunks.ca>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C373D1AE3DE for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 10:50:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] 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 RTysvhF1-119 for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 10:50:16 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA841AE04B for <perpass@ietf.org>; Mon, 9 Dec 2013 10:50:16 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id B7F8B80A04; Mon, 9 Dec 2013 13:50:10 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA51E80A01 for <perpass@ietf.org>; Mon, 9 Dec 2013 13:50:10 -0500 (EST)
Date: Mon, 09 Dec 2013 13:50:10 -0500
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: perpass <perpass@ietf.org>
In-Reply-To: <CAMm+LwgfXVc=ED7piSnoPrZPTs_Y+m5ShxJcEbSAXF4DsFoo4g@mail.gmail.com>
Message-ID: <alpine.LFD.2.10.1312091336480.315@bofh.nohats.ca>
References: <CAMm+LwijWwanC+KLaSC-Kgq4vP=8in8Juo2Gbd=URh4zVf55nA@mail.gmail.com> <52A5D9C5.1050700@bbn.com> <CAMm+LwgfXVc=ED7piSnoPrZPTs_Y+m5ShxJcEbSAXF4DsFoo4g@mail.gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ???
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 18:50:17 -0000

On Mon, 9 Dec 2013, Phillip Hallam-Baker wrote:

> At any rate, I think the point is made sufficiently that NULL ciphers in legacy suites do not represent a policy precedent against the
> PERPASS work.

I think that calling something NULL ENCRYPTION is pretty clear. There
are clear testing and benchmark reasons to keep these. However, to bring
this back to perpass focus, it _is_ our job to ensure these proposals
are never picked automatically, or are ever part of a "default set" or
proposals that are valid.

Speaking for libreswan, we only allow it when configured specifically
using, eg esp=null-md5 and even then we issue a warning:

# ipsec auto --up  westnet-eastnet-null
104 "westnet-eastnet-null" #1: STATE_MAIN_I1: initiate
003 "westnet-eastnet-null" #1: received Vendor ID payload [Dead Peer Detection]
003 "westnet-eastnet-null" #1: received Vendor ID payload [FRAGMENTATION]
106 "westnet-eastnet-null" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "westnet-eastnet-null" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "westnet-eastnet-null" #1: received Vendor ID payload [CAN-IKEv2]
004 "westnet-eastnet-null" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "westnet-eastnet-null" #2: STATE_QUICK_I1: initiate
003 "westnet-eastnet-null" #2: You should NOT use insecure/broken ESP algorithms [ESP_NULL (0)]!
004 "westnet-eastnet-null" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP<0xESPESP xfrm=NULL_0-HMAC_MD5 NATOA =none NATD=none DPD=none}

That said, I think it is more much more important to ensure we get rid
of algorithms people still use not being aware their strength is as
good as NULL. We still cannot remove 1DES code from our tree because it
will break "legitimate" deployments. As an opensource vendor, we have
subverted these to be compile-time options (default off), and tell
vendors not to enable that compilation option.

As for whether we should move AH, Transport Mode, Compression,
Narrowing, MD5, and other IPsec ideas to historirc, that is probably
better discussed on the ipsecme list.

Paul