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