Re: [TLS] ALPN concerns

[Nikos Mavrogiannopoulos <[e-mail]>]

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.

regards,
Nikos