Re: [TLS] Next Protocol Negotiation 03

[Michael D'Errico <[e-mail]>]

Nikos Mavrogiannopoulos wrote:
> 
> My understanding is, that instead of having a simple:
> ClientHello: I want protocols A, or B.
> ServerHello: Let's talk A.
> 
> We have
> ClientHello: I want to negotiate a protocol
> ServerHello: I have A or B.
> ...
> Client NPN message: Let's talk A.
> 
> That's really different from any other negotiation in TLS.
> I understand that you might want to hide the protocol that
> they are actually talking, but is this the way to do it?

Hiding the protocol is problematic if the server wants to use
the NextProtocol as part of its certificate selection process.
It would need to be in the ClientHello extension.

Also, if we're going to go down the road of sending Handshake
messages after ChangeCipherSpec (NPN, concealed client cert),
then I'd suggest that there should be no order imposed on these
messages; otherwise the state machine logic could get unwieldy
quickly, not to mention the difficulty in writing the specs.

Further, we should not create another registry of protocol
names (the Google Tech Note lists "http/1.1", "spdy/1", and
"spdy/2" as being in use).  Please leverage the existing IANA
list of well-known services for this (so we don't need to
duplicate definitions for "smtp", "imap4", etc.), along with
the standard "x-" prefix for anything experimental like SPDY
("x-google-spdy-2" as an example).

Mike