Re: [TLS] Next Protocol Negotiation 03

[Nikos Mavrogiannopoulos <[e-mail]>]

On 04/24/2012 10:56 PM, Adam Langley wrote:


> 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.


Some comments on the current draft. It is quite a complex negotiation.
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?

Say that B is TOR. Wouldn't a middleware terminate the connection anyway
if the server supports tor? So that complication doesn't
really buy privacy or protection against middlewares.

I'd suggest that you define NPN using the simple ClientHello/ServerHello
methods, and then for privacy add a new extension NegotiatePrivate or so
that would exchange after Client ChangeCipherSpec:
ClientPrivateExtensions: client_hello_extension_list<0..2^16-1>;

and after the server Changecipherspec:
ServerPrivateExtensions: server_hello_extension_list<0..2^16-1>;

and this format is not NPN specific. Any extension
can be negotiated like that.


regards,
Nikos