Subject: [quicwg/base-drafts] Second flight DOS Attack with Client Clear Text packets. (#1018)

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Dec 2017 16:46:54 -0800

The spec says "Once the TLS handshake is complete, both peers MUST ignore unprotected packets.
 From that point onward, unprotected messages can be safely dropped." I wish that were true. But truthiness here depends of what you mean by "the TLS handshake is complete."

The current spec says that the second flight of the client is carried in a clear text handshake message. This was decided to align with TLS over TCP, because the proof of correctness is easier to establish if the transmission of the Finished message does not depend on the encryption key used for application messages. OK, maybe.

That rule means that if the clear text handshake message is lost, clients will repeat it. They will normally be using a different packet sequence number, so as to elicit a new acknowledgement -- because after all, the packet might have been received but the ACK may have been lost.

The problem is that third parties can also replay this "Finished" message. They can do that a number of times, using different packet sequence numbers, including numbers that the client might have used for its own data packets. Consider this:

1) Client sends Finished message with sequence number 5;
2) Adversary races Finished message with sequence number 6;
3) Client sends first HTTP command in 1-RTT message with sequence number 6.

This will probably cause the application to fail, as the server will "acknowledge" packet number 6 when it receives the duplicate "Finished" message, and ignore the 1-RTT packet because the packet sequence number has already be seen. 

In fact, the adversary does not need to race the first client packet. It could just as well use some higher numbers, or do that multiple times. If just one packet gets accepted, it will create a "hole" in some application stream. If the adversary feels lucky, it may not even need to place a copy of the Finished message there. Any old duplicate ACK might work just as well, as long that the server does not systematically reject the clear text messages.

The server will only be in a position to drop these incoming packets after receiving the "ACK of ACK" that shows that the acknowledgement of the finished packet has been received. That leaves a window of at least 1 RTT.

The simplest protection, IMHO, is to just start sending 1-RTT packets as soon as the keys have been negotiated, and to start rejecting clear text messages as soon as 1-RTT packets have been successfully received. That would require sending the second client flight using 1-RTT packets, instead of handshake packets.

There may be other solutions, such as using different sequence numbers for clear-text packets and protected packets. But that feels more complicated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1018

---

From: ianswett <[email-masked]>
Date: Mon, 18 Dec 2017 15:09:52 +0000 (UTC)

I would agree that sending 1-RTT packets as soon as they keys have been negotiated seems like the most robust solution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1018#issuecomment-352452551

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Dec 2017 22:35:53 +0000 (UTC)

But that will also violate the conditions of the analysis of TLS.

The "attack" here is an off-path attacker can cause packets to be dropped if they can observe and replay the client's Handshake packets.  It only happens if they can race the legitimate packets and the consequence is a performance hit.

I'm having a hard time getting excited about this.  Yes, it is theoretically possible to harden against this, but it doesn't seem that important.

An alternative approach that doesn't introduce these risks would be to drop Handshake packets without consuming the packet number in the case where you have already received that flight.  It wouldn't avoid the exposure to a race, but it would prevent an attacker from consuming packet numbers after the handshake completes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1018#issuecomment-352580111

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 23:38:55 +0000 (UTC)

I'm also having a hard time getting excited about the idea that if the Finished message can be securely sent under TLS 1.3's handshake_traffic_secret, but can't be securely sent under the same handshake_traffic_secret plus encryption with any other key known to both sides.  Have we asked researchers to look at this, or is the issue simply that we're outside the bounds of the analysis they already did?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1018#issuecomment-352592814

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 Dec 2017 00:39:35 +0000 (UTC)

I can understand that the researchers are worried about exchanging data prior to the client finished message. If I think about it some more, there are really three phases in the TLS connection:

1) Before key are exchanged. 
2) After key exchange is complete, i.e. after the client receives the server's first flight.
3) After the client's "finished" message has been received.

The client can detect MITM after receiving the server's Finished, but the server can only do so after receiving the client's Finished. Traffic sent by the server before receiving the client's Finished is potentially exposed to MITM. Traffic sent after that is not, barring spoofed credentials.

So yes, I can see that these conditions somehow affect the proofs. Although I would really like to know how exactly they do.

If that's the case, we should consider two changes in QUIC:
1) Reintroduce a server clear text message, for the first flight.
2) Specify that the handshake messages are protected by a key derived from the handshake, as they are in fact in TLS. This will cover the client's second flight, and possibly additional handshake messages required for client auth and ack of it by the server.

Having this kind of protection would suppress attacks happening after the server's first flight is received, at the cost of establishing another key for the handshake. The cost of encryption would be pretty much the same as with the current connection ID specific AEAD.

I think that would be the right thing to do, if we want to abide by the researcher's desires. Barring that, I am willing to explore Martin's suggestion to drop Handshake packets without consuming the packet number after the Finished message has been received.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1018#issuecomment-352602961