[TLS] Next Protocol Negotiation - Some comments

[Alfredo Pironti <[e-mail]>]

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