Re: [TLS] Next Protocol Negotiation - Some comments

[Adam Langley <[e-mail]>]

On Thu, Jul 12, 2012 at 10:09 AM, Alfredo Pironti
<[e-mail]> wrote:
> Briefly, suppose a MItM wishes to know which 'selected_protocol' the
> client is sending to the server. He could downgrade protocol
> version/ciphersuite in the server hello, let the client send its
> encrypted "EncryptedExtensions" message, and then let the session
> fail. Decrypting the message once could be enough to spot that the
> server is offering a specific 'selected_protocol' (or at least that
> the client believes the server can offer it, even if not advertised),
> and so ban the server in the future.

Yep, especially if the client will allow NULL encryption ciphersuites.
Quite possibly this should be noted in the spec.

The purpose of encrypting and padding the protocol is to prevent
large-scale, casual interference which has become so common and
damaging to other protocols. It's certainly adding grey to TLS's
otherwise binary world, but that's not to say that it's not useful.

> On a related topic, the EncryptedExtension message is padded, to avoid
> leaking the length of next-protocol name. I would add an
> implementation caveat here. Note that handshake messages can be
> fragmented. In particular, if an implementation prepares the
> selected_protocol field and sends it to the record, then prepares the
> padding field and sends it to the record, we may end up with two
> encrypted fragments where the first reveals the length of the
> selected_protocol field. An implementation should ensure this message
> is not fragmented in the above way (or not fragmented at all). I
> believe it's quite unlikely implementations out there would behave
> like this, but again, we may want to be explicit on this.

Yep, probably another point to be mentioned, thanks. (Although the
reality is that fragmenting handshake messages doesn't actually work
in the real world due to bugs.)

> Finally, if I was to implement this extension, I would not know what
> to do in case of errors. For example, if I'm the server, and I receive
> an unsupported 'selected_protocol' from the client, what should I do?
> Send an alert (which one)?

That's deliberately unspecified at the moment because I don't know
what the right behaviour is. What'll actually happen at the moment is
that servers will use their default protocol if they don't recognise
the requested protocol. But I don't think it's clear enough yet to say
whether that's the right behaviour or not.


Cheers

AGL