Subject: Re: [TLS] Next Protocol Negotiation 03

From: Andrei Popov <[email-masked]>
Date: Wed, 14 Nov 2012 20:31:59 +0000

A number of issues have been raised with regard to the TLS NPN Internet-Draft, including the downgrade attack described by Marsh. Is an updated draft in the works?

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marsh Ray
Sent: Wednesday, April 25, 2012 12:33 PM
To: Adam Langley
Cc: [email-masked]
Subject: Re: [TLS] Next Protocol Negotiation 03

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
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Nov 2012 17:51:39 -0500

> A number of issues have been raised with regard to the TLS NPN Internet-Draft, including the downgrade attack described by Marsh. Is an updated draft in the works?

I've nothing to add to -04 at the moment.

I'm afraid you'll have to highlight the attack that you're referring
to. Since the messages are covered by the Finished hash, there's no
downgrade attack that doesn't also work against anything else in the
handshake.

The major point of contention that I'm aware of is the addition of
encrypted extensions, rather than just negotiating in the client and
server hello messages, in the clear.

This is clearly additional complexity and the benefit is limited by
the fact that the server still advertises in the clear. It's the best
that can be done without adding additional round trips.

On the complexity side, there haven't been any significant issues with
implementations of the similar version of NPN that's currently used by
SPDY, except in the case of one hardware accelerator product who had
issues. They, however, appear to have figured it out.

On the benefits side, although having the server advertise in the
clear is unfortunate, that's only needed for supporting client
fallback. If the client knows what protocol it supports, it can simply
choose it and that choice is protected. Since we're in this position
partly because TCP port numbers have become unusable, it seems to be
the height of folly to create another cleartext selector and expect a
different result.

So those reasons, I believe that the current NPN design is the correct one.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Wed, 14 Nov 2012 23:30:09 +0000

Here is an example active attack which could reveal the negotiated protocol:
- MITM downgrades the cipher during TLS handshake.
- MITM can decrypt EncryptedExtensions message and find out which application protocol has been negotiated between the server and the client.
- Finished messages are exchanged, at which point the attack is detected and the session is aborted. But the attacker knows the application protocol that is likely to be negotiated between this server and this client in the future.

Negotiating in the client and server hello messages (in the clear) achieves the goal of reducing round trips. The added complexity of EncryptedExtensions does not provide much security value.

In those situations where the next protocol negotiation needs to be confidential, one could use TLS renegotiation. Alternatively, the next protocol can be negotiated after exchanging Finished messages, outside of the TLS handshake.

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, November 14, 2012 2:52 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [TLS] Next Protocol Negotiation 03

I'm afraid you'll have to highlight the attack that you're referring to. Since the messages are covered by the Finished hash, there's no downgrade attack that doesn't also work against anything else in the handshake.

The major point of contention that I'm aware of is the addition of encrypted extensions, rather than just negotiating in the client and server hello messages, in the clear.

This is clearly additional complexity and the benefit is limited by the fact that the server still advertises in the clear. It's the best that can be done without adding additional round trips.

On the complexity side, there haven't been any significant issues with implementations of the similar version of NPN that's currently used by SPDY, except in the case of one hardware accelerator product who had issues. They, however, appear to have figured it out.

On the benefits side, although having the server advertise in the clear is unfortunate, that's only needed for supporting client fallback. If the client knows what protocol it supports, it can simply choose it and that choice is protected. Since we're in this position partly because TCP port numbers have become unusable, it seems to be the height of folly to create another cleartext selector and expect a different result.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Nov 2012 19:09:03 -0500

> - Finished messages are exchanged, at which point the attack is detected and the session is aborted. But the attacker knows the application protocol that is likely to be negotiated between this ser…

Ah yes, I'm sorry, in my mind I was trying to think of a way to
downgrade the protocol when you referenced that.

That attack can certainly cause the protocol to be sent using the
weakest cipher the the client supports (which is generally 3DES for
the clients in question).

However, I don't believe that your conclusion that this demonstrates
that the complexity isn't justified is correct. I think everyone
recognises that traffic is moving towards port 80 and 443 because of
filtering of TCP ports by middleware. If we create another plaintext
protocol negotiation then I'll be back here in a few years time with a
draft for NPN2 - because the plaintext negotiation will also be the
target of filtering.

The fact that a middlebox can perform an active attack and get the
protocol encrypted with 3DES doesn't affect that reasoning. I agree
that this is shade of security gray which is generally not something
that TLS deals with. None the less, I believe that it still has
significant value even through it's not white: the end-to-end
principle is worth defending.

Cheers

AGL

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Nov 2012 16:56:31 -0800

> - Finished messages are exchanged, at which point the attack is detected and the session is aborted. But the attacker knows the application protocol that is likely to be negotiated between this ser…

This is arguing that the EncryptedExtensions message might be misnamed, in that an active MITM who doesn't mind breaking the exchange can view it. This is similar to identity-exposing attacks in IKEv1. It's a design tradeoff.

> Negotiating in the client and server hello messages (in the clear) achieves the goal of reducing round trips. The added complexity of EncryptedExtensions does not provide much security value.

I like the current design of NPN better than negotiating in the clear (and thus giving passive MITM firewalls another place to block based on policy). It doesn't feel that EncryptedExtensions is complex and it forces an MITM who wants to know the protocol being used to become noticeable active attackers.

> In those situations where the next protocol negotiation needs to be confidential, one could use TLS renegotiation. Alternatively, the next protocol can be negotiated after exchanging Finished messa…

Renegotiation adds round trips and complexity, as we have seen in this WG. "Outside of the TLS handshake" just pushes this off to layer 7 and forces a change to all application servers and clients to do the negotiation. It seems cleaner to keep this in TLS.

--Paul Hoffman

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Nov 2012 19:41:07 +0000

> Renegotiation adds round trips and complexity, as we have seen in this WG. "Outside of the TLS handshake" just pushes this off to layer 7 and forces a change to all application servers and clients…

The servers and clients (and/or middleware that they use) will likely need an update anyway, in order to:
1. Enable the TLS-NPN extension;
2. Communicate next protocol options to the TLS layer;
3. Extract the negotiated protocol info from the TLS layer;
4. Switch to the negotiated protocol.

Andrei Popov