Re: [TLS] Next Protocol Negotiation 03

[Marsh Ray <[e-mail]>]

On 04/25/2012 11:40 AM, Adam Langley wrote:
>
> The idea would be that the server doesn't advertise Tor, or any other
> possibly suspect protocol. Rather the client would simply select "tor"
> as the protocol.
>
> The fact that the server advertises is unfortunate, but necessary to
> avoid an extra round trip. I'd rather see NPN in the clear as a
> standard ClientHello/ServerHello negotiation then take an extra round
> trip.

I don't speak for the Tor project, but I don't think this design is 
going to meet anyone's requirements for serious censorship resistance.

Nevertheless, giving some privacy to the significant bits of the 
handshake in a way that is more latency-friendly than full renegotiation 
is very appealing. It seems likely to enable new and interesting 
applications, SPDY is just one good example.

Unfortunately, we must keep in mind that anything sent before receiving 
the other endpoint's Finished message is going to raise similar 
considerations as False Start. The security guarantees provided to this 
data are somewhat squishy, as they tend to depend on all sorts of 
not-yet-fully authenticated details of the in-progress negotiation. As 
we saw with ServerKeyExchange DHE_RSA/ECDH, even the future introduction 
of new key exchanges and cipher suites can change these properties.

In the case of something like NP(N), a MitM might utilize a downgrade 
attack which allows him to decrypt the client's NP record (possibly 
offline). This could break the handshake, but clients are so eager to 
retry the user might not even notice.

So maybe any facility for "privately" negotiating handshake extensions 
ought to be held to a clear standard lest we invite disaster, namely, it 
should provide the same security guarantees as are provided to 
application data.

- Marsh