Re: [TLS] ALPN concerns

Nikos Mavrogiannopoulos <> Mon, 09 December 2013 14:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AFAA71AE304 for <>; Mon, 9 Dec 2013 06:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.903
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ekBaAtzI49MH for <>; Mon, 9 Dec 2013 06:08:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 636D41ADF7F for <>; Mon, 9 Dec 2013 06:08:07 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id rB9E7rZs009828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 09:07:54 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id rB9E7oiB032027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 09:07:51 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Brian Smith <>
Date: Mon, 09 Dec 2013 15:07:50 +0100
In-Reply-To: <>
References: <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on
Cc: "<>" <>, Peter Gutmann <>
Subject: Re: [TLS] ALPN concerns
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2013 14:08:09 -0000

On Mon, 2013-12-09 at 05:32 -0800, Brian Smith wrote:

> >> As far as I've been led to believe, ALPN exists primarily to allow MitM to more easily
> >> inspect what protocol the application is speaking and possibly block the application,
> >> with as low of a cost to the MitM as possible--i.e. exactly the opposite goal of
> >> everything we discussed at IETF88 in perpass and in other discussions.
> >
> > No, ALPN exists primarily to negotiate an application protocol without incurring extra
> > round-trips, to allow the server to pick the application protocol and present the
> > corresponding identity, and to align with the existing TLS extensions.
> I have discussed the ALPN vs NPN issue with Eric Rescorla (co-chair of
> this working group, alongside Joseph Salowey from Cisco) multiple
> times, and each time Eric said that allowing passive MitM devices to
> know which protocol is being used is important, and that this is an
> advantage for ALPN over NPN. I will let him explain why, if it hasn't
> already been explained on the list. FWIW, I strongly disagree that it
> should be a goal to allow passive MitM to know which protocol is being
> used. In fact, I think that we should have a goal of protecting the
> protocol information so that passive MitM has a much more difficult
> time of determining with certainty the protocol being used.

I think we need to clarify not only the reason we need the protocol
negotiation in TLS but most importantly, how we expect implementations
to support it.

If we expect a lightweight super-server or a firewall to do the mapping
of the incoming protocol requests in the client hello to the appropriate
servers, then having NPN means that the firewall or super-server has to
terminate TLS in order to discover the intended protocol. That's pretty
unacceptable in many scenarios, not only because of the unnecessary load
on the firewall/super-server, but also because it makes TLS client
authentication very hard to impossible.

If we expect that the incoming protocol requests will be handled by a
single server application (that is no super-servers or a firewall will
be involved to distribute the protocols)... then NPN suits that
scenario, and provides more than ALPN. However one server handling all
possible protocols feels like a very restricted use-case.