Re: [TLS] Next Protocol Negotiation 03

[Yoav Nir <[e-mail]>]

Hi Adam

I support the adoption of NPN.

However, I would like to get a statement from Google, that if the output from the working group is different from what is running on Google's servers (and Chrome and Firefox) right now, those servers and clients will change to match the standard. Otherwise, we are going to have one of two outcomes:
 - the TLS working group rubber-stamps Google's proposal, perhaps decorating it with some nice security considerations.
 - the TLS working group creates a different standard, and implementers can choose between the Google NPN and the IETF NPN, and more that likely, implement both.

At HTTPBIS in Paris There was such a statement about SPDY. Can you make one about NPN?

I can think of two things that might prove contentious:
 1. Using the extension and handshake numbers. I would hope that IANA assigns those numbers rather than forcing a transition period, but that should not be a problem as both clients update without asking the user, and the servers are under your control. So it's not a problem either way.

 2. Some may consider the use of a new handshake message as superfluous. You could have the client advertise that it supports http/1.1 and spdy/2.0, and then the server chooses one in the ServerHello. The downside is that an eavesdropper can then know what the protocol inside the TLS connection is. I don't know if the benefit of hiding that information is worth a new handhsake message, which also changes the state machine.

Yoav

On Apr 24, 2012, at 11:56 PM, Adam Langley wrote:

> With httpbis active, several people have suggested that it's time to
> make another pass at making NPN a little more formal.
> 
> Previous drafts have omitted some details so that the more important
> aspects were clearer. Paul Hoffman also made a valiant attempt [2] at
> making it more "IETF friendly" to see whether that would get anywhere.
> 
> In contrast, the current draft [1] is complete and sufficient to
> produce an interoperable implementation with what's running on
> www.google.com.
> 
> Perforce, it includes the current extension and handshake message
> numbers. I understand that using these numbers without permission has
> upset some people. However, we stand up, evaluate and tear down TLS
> work at a rate far in excess of what the WG could usefully process.
> Standardising every experiment before testing it would waste RFCs and
> allocations, not to mention years. Therefore the extension and
> handshake numbers were randomly generated.
> 
> NPN is included in several TLS implementations and used quite
> regularly on the Internet and I would like the TLS WG to consider its
> adoption.