Subject: [TLS] Next Protocol Negotiation - Some comments

From: Alfredo Pironti <[email-masked]>
Date: Thu, 12 Jul 2012 16:09:24 +0200

Hello all,

It seems to me that the NPN extension is vulnerable to some known
limited version/ciphersuite rollback attack, which was affecting, for
example, the proposed False-Start protocol variation [1].

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.

If we accept this weakness, I believe it would be at least worth
mentioning it in section 6.

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.

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)?

Cheers,
Alfredo

[1] http://www6.ietf.org/mail-archive/web/tls/current/msg06933.html

---

From: Adam Langley <[email-masked]>
Date: Thu, 12 Jul 2012 10:35:31 -0400

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

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

> 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