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

Yoav Nir <ynir@checkpoint.com> Mon, 09 December 2013 13:48 UTC

Return-Path: <ynir@checkpoint.com>
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 ECF591AE2C5 for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 05:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 YumPUysKgCPs for <perpass@ietfa.amsl.com>; Mon, 9 Dec 2013 05:48:51 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CACF71AE2BF for <perpass@ietf.org>; Mon, 9 Dec 2013 05:48:50 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rB9DmIKh029297; Mon, 9 Dec 2013 15:48:19 +0200
X-CheckPoint: {52A5C6B7-F-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 15:47:13 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [perpass] NULL Cipher RFC 2410 to HISTORIC ???
Thread-Index: AQHO9IFu4/5YzgvJX0aB14ruAS2e45pLIR6AgAAOqACAAAmtAIAAOKIwgAA/GICAAA6bAA==
Date: Mon, 09 Dec 2013 13:47:12 +0000
Message-ID: <2611BD08-EA51-42DF-BFDF-4031DEDA9F3F@checkpoint.com>
References: <CAMm+LwijWwanC+KLaSC-Kgq4vP=8in8Juo2Gbd=URh4zVf55nA@mail.gmail.com> <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> <CAMm+LwjYUZN6b81=V0dm1y_oW9Y+Px5PHsenbXetMkpY=zq6zw@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> <CAMm+Lwhq0Sk9dgkwADA9O9neUGC2MTMWpUU9H3zJSz+ye6mdXQ@mail.gmail.com>
In-Reply-To: <CAMm+Lwhq0Sk9dgkwADA9O9neUGC2MTMWpUU9H3zJSz+ye6mdXQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.111]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_2611BD08EA5142DFBFDF4031DEDA9F3Fcheckpointcom_"
MIME-Version: 1.0
Cc: perpass <perpass@ietf.org>, Merike Kaeo <merike@doubleshotsecurity.com>
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 13:48:53 -0000

On Dec 9, 2013, at 2:54 PM, Phillip Hallam-Baker <hallam@gmail.com<mailto:hallam@gmail.com>> wrote:

On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> wrote:
Phil,

The issue is not that ESP needs a NULL cipher. It's that AH wouldn't traverse NAT, and so they needed ESP to do the work that AH was designed to do.

I understand that, though the fact that ESP with authentication would work through NAT but not AH seems remarkably odd to me. It suggests that the design is wrong.

Of ESP (because it doesn't protect the IP header), or of AH (because if cannot traverse NAT) ?


That flags a design error in the protocol AFIAK.

As a remote access protocol, IPSEC has fallen far short of satisfactory.

I don't think anyone is arguing against that. We wouldn't implement L2TP over IPsec or stuff IP packets into TLS connections if it was.

It has been necessary to install a plug in to use every corporate VPN I have used to date.


But beyond that little technicality, it stands out that they standardized AH at all. So they felt that there was a need for integrity-only IPsec. I guess part of this is that the perceived threats were different - there was less personal information on the Internet, and IPsec (unlike TLS) is much concerned with protecting non-confidential stuff like DNS, routing protocols. Today, about the only good use case I can think of that doesn't ever need confidentiality is NTP, and I don't know why we would want to design a protocol specifically for securing NTP.

And to do authentication only twice seems even stranger.


Another part is that this was 1996 and in 1996 you had the "Pentium Pro" with a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not today's processors that do 4 Gbps per core with AES-GCM.

That is not the motivation that the RFC suggests.

It doesn't, but at the time you couldn't say "just encrypt everything" without seeming out of touch with reality. Today, you can.

BTW: this is not unique to IPsec. TLS also defines some NULL encryption ciphersuites.

I know, but the problem is that people are now pointing to the NULL ciphers as precedent.

The current algorithm draft ([1]) still has NULL as MTI. It's interesting that opinions range from MTI to HISTORIC.

Yoav

[1] http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01#section-2.2