Subject: Re: [TLS] Review of draft-agl-tls-nextproto-00

From: Brian Smith <[email-masked]>
Date: Sat, 20 Aug 2011 03:46:04 -0700 (PDT)

Eric Rescorla wrote:
> MOTIVATION
> It's unclear from the draft what the motivation for this work is.

Practically, it allows multiple protocols to be offered on the same host:port. In particular, it allows SPDY and HTTP to both use port 443. Mozilla will use this extension (or the previous version) for exactly this purpose. In addition, I think we will also eventually use it for all of our TLS-based communication, to reduce the risk of cross-protocol attacks.

> However, WebSockets does not use NPN; the HyBi working group
> explicitly rejected NPN because it would have required the use of TLS
> at all times. I'm not saying I agree with this, but it's what
> happened. Instead, the HyBi WG designed their own application-layer
> handshake which is intended to thwart cross-protocol
> attacks. Similarly, the other major WG which is currently concerned
> with cross-protocol attacks, WebRTC, is not interested in NPN but
> rather is using an ICE-based handshake prior to sending traffic. What
> IETF protocols have a demand for this functionality?

SMTP, HTTP, IMAP, WebSockets. (There are email providers that offer IMAPS and SMTPS over port 443.)

> ENCRYPTED NEGOTIATION
> This document specifies a partially encrypted negotiation mechanism:
> the server advertises some set of protocols (in the ServerHello)
> and the client specifies a specific protocol (in a separate
> handshake message inserted between the CCS and the Finished).
> The client's announcement need not match any of the protocols
> specified by the server. Thus, the negotiation is partly encrypted.
> 
> The reason for this appears to be that this mechanism is designed to
> prevent network attackers from learning which next protocol is being
> requested. (See Section 4). I'm extremely skeptical of this objective:

<snip>

> This wouldn't be a big deal except that this highly imperfect
> functionality comes at significant architectural cost. This mechanism
> is clearly more invasive and complicated than necessary to accomplish
> the goal of addressing cross-protocol attacks.

We should not send data unprotected when we can send it protected. I think this is a more important design goal.

We could generalize the mechanism so that the new message consists of a sequence of TLS extensions, to avoid creating new message types in the future.

Cheers,
Brian