Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 12 December 2013 16:08 UTC
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAAB1AE345 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 08:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 bVJpcdVc9YpP for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 08:08:58 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E00391AE342 for <tls@ietf.org>; Thu, 12 Dec 2013 08:08:57 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBCG8hru005123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Dec 2013 11:08:43 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBCG8fhU026966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Dec 2013 11:08:42 -0500
Message-ID: <1386864521.31585.57.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Yoav Nir <ynir@checkpoint.com>
Date: Thu, 12 Dec 2013 17:08:41 +0100
In-Reply-To: <C634E116-DF05-4325-80DB-0ECA5AFEC3FC@checkpoint.com>
References: <CAFewVt7SS9ud8J=6VtR-Zv-9bhaTHEnjT8XD+ULaRSVUkYftaQ@mail.gmail.com> <CABcZeBM=gOZrm1EGDSer2RmGsbOoxPDSQK5t-+LZmWaB6a_swQ@mail.gmail.com> <CAFewVt6ufrcteLfKA+r_7kby3fNRcwG410FJ1enu=pVO=xeBBQ@mail.gmail.com> <CABcZeBN=xvFG_515immvF_FuUvGXnDThrWnj_rr8Ct8Wi1jnoA@mail.gmail.com> <CA+BZK2rusGfDVAEA3vM4+WJU_Gmve2Z7P+ZEyBWBiyEEZzmsuA@mail.gmail.com> <C634E116-DF05-4325-80DB-0ECA5AFEC3FC@checkpoint.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 16:09:00 -0000
On Thu, 2013-12-12 at 14:42 +0000, Yoav Nir wrote: > I preferred ALPN for the following reasons: > * ALPN leaks very few bits of relevant information. For > starters, it's HTTP/1 vs HTTP/2, which is not interesting at > all, as they convey the same information. There are > suggestions to place more things there, like various mail > protocols. Whether that happens or not, knowing that someone > is reading mail rather than browsing the web is a small amount > of information. This should be balanced against: I also prefer ALPN, for the additional reasons, that (1) uses the standard TLS extension mechanism, and (2) a load balancer, or super-server can distribute the protocols indicated in ALPN to various (different) servers. That cannot be done in any efficient way using NPN. While I believe privacy concerns are important, in that case nothing is revealed to an adversary that was not available before (i.e., the service was always known due to TCP port number). Moreover applications that require privacy can always use steganography and advertise a phony protocol. TLS has specific design goals, and hiding the service and the connecting peers were never among them (don't say I agree with that). Adding both is a major redesign, which I agree with the calls to be postponed to TLS 1.3 (or 2.0). Otherwise if every extension designs its privacy goals differently, we get a protocol full of hacks that doesn't allow to be improved in a sensible way. regards, Nikos
- [TLS] A new consensus call on ALPN vs NPN (was AL… Brian Smith
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Hannes Tschofenig
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Tom Ritter
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Stephen Farrell
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Eric Rescorla
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Daniel Kahn Gillmor
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Stephen Farrell
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Brian Smith
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Yoav Nir
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Bill Frantz
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Daniel Kahn Gillmor
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Yoav Nir
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Brian Smith
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Watson Ladd
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Brian Smith
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Brian Smith
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Wan-Teh Chang
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Paul Hoffman
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Watson Ladd
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Eric Rescorla
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Ralf Skyper Kaiser
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Yoav Nir
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Nikos Mavrogiannopoulos
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Alyssa Rowan
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Stephan Friedl (sfriedl)
- Re: [TLS] A new consensus call on ALPN vs NPN (wa… Bill Frantz