[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Review of draft-agl-tls-nextproto-00
From:       Brian Smith <bsmith () mozilla ! com>
Date:       2011-08-20 10:46:04
Message-ID: 1360415263.273856.1313837164056.JavaMail.root () zimbra1 ! shared ! sjc1 ! mozilla ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]