Subject: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)

From: Nico Williams <[email-masked]>
Date: Fri, 15 Mar 2013 16:59:50 -0500

On Fri, Mar 15, 2013 at 4:45 PM, Eric Rescorla <[email-masked]> wrote:
> At today's TLS WG f2f meeting we had rough consensus to adopt
> ALPN as the solution to the upper-layer protocol negotiation problem
> posed to us by the HTTP WG.
>
> if you have an opinion on this topic and were not at the meeting,
> please send a message to the mailing list and/or the chairs by
> Friday March 29.

I believe that privacy protection for as much as possible of the
application layer negotiation is highly desirable.  In this sense I
think the consensus for ALPN is mistaken.  I do believe NPN is too
complex, and in that sense the consensus for ALPN is correct.

Can we find a middle of the road?

My compromise proposal is based on providing privacy protection for
the record type in TLS (post-CCS, of course) -- a feature that should
be desirable anyways and separately (e.g., to hide re-negotiation from
non-MITM middleboxes).  Such a feature would allow a post-handshake
non-application-type record for optimistic application protocol
negotiation (zero extra round trips in the optimal case, one more
round trip in the pessimal case).

Nico
--

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 16 Mar 2013 00:54:43 +0200

On 15.3.2013, at 23.59, Nico Williams <[email-masked]> wrote:
> I do believe NPN is too
> be desirable anyways and separately

I'm sorry to point this out, but I think your proposal is actually much more complex to implement than the NPN proposal. No other extension that I can think of have changed the data record format, and mixing data records with handshake packets would need a rather big refactoring at least in my implementation.

As I mentioned before, NPN without the plaintext server response would work in preventing the most obvious firewall filtering, so if that is desired the draft should be reworded more clearly to list only conflicting protocols serving the same content in ServerHello.

That being said, I do not object choosing ALPN over NPN. It is the most simple and most obvious implementation, and if there's trouble with firewalls one can always fake the protocol name or not use ALPN at all.

Juho

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Mar 2013 18:11:21 -0500

> I'm sorry to point this out, but I think your proposal is actually much more complex to implement than the NPN proposal. No other extension that I can think of have changed the data record format,…

There'd not be any refactoring: there'd still be a record type, just protected.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Mar 2013 18:08:10 -0400

> round trip in the pessimal case).

I'd prefer a solution that is architected with this goal in addition to the original goals of SSL/TLS.  I'm concerned that an extension to TLS 1.2 will be an improvement, but it will be far short of a handshake that was structured to that set of goals.

Russ

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Mar 2013 18:40:57 -0500

> I'd prefer a solution that is architected with this goal in addition to the original goals of SSL/TLS.  I'm concerned that an extension to TLS 1.2 will be an improvement, but it will be far short o…

OK, but ALPN/NPN are the first extensions that negotiate
application-layer things[* ah, not really].  TLS has generally
(ignoring BEAST/CRIME/...) intended to protect application data.  TLS
has even been able to protect user certificates' privacy (module
re-nego bug) with the caveat that re-nego happens is externally
visible.

The point is: providing privacy protection for app data *prior* to
handshake completion was never really a goal of TLS.  It'd be great to
make it a goal _now_.

If we want to generally send privacy-protected application data before
the handshake completes then we definitely need something along the
lines of NPN.  I think it's worth having such an extension.  Count
this as more in favor of NPN than ALPN.

Nico
-- 

[*] OK, not really true.  There's the authz RFC (RFC5878) and the user
mapping RFC (RFC4681).  And I proposed an extension
(draft-williams-tls-app-sasl-opt) once for negotiating application
protocol *and* performing the first round trip of SASL authentication
in the TLS handshake.