Subject: [quicwg/base-drafts] Can Finished be sent as 1-RTT data? (#785)

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Sep 2017 16:44:04 +0000 (UTC)

I know that in TLS 1.3, the answer is no. But the TLS answer applies to TLS over TCP, for which TLS manages the transition from handshake data to application data. QUIC is arguably different. The stream zero frame will carry the Finished message as an encrypted handshake message. But the spec is a bit ambiguous as to whether this stream zero frame shall be carried as "Client Clear Text" or "1-RTT Data". 

I would much prefer 1-RTT data, because of repetition handling. If we imposed Client Clear Text, and the packet is lost, the stream zero frame will have to be retransmitted again as client clear text. That means interleaving clear text data and encrypted data within a single set of sequence number, and I am convinced that that can be abused to carry some kind of denial of service.

-- 
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/785

---

From: ekr <[email-masked]>
Date: Wed, 20 Sep 2017 17:27:42 +0000 (UTC)

Note that there are cryptographic reasons for using different keys. This
was one of the big reasons for the TLS 1.3 key schedule being the way it
is. So I'd really much rather have it be in Client Clear Text.

On Wed, Sep 20, 2017 at 9:44 AM, Christian Huitema <[email-masked]
> wrote:

> I know that in TLS 1.3, the answer is no. But the TLS answer applies to
> TLS over TCP, for which TLS manages the transition from handshake data to
> application data. QUIC is arguably different. The stream zero frame will
> carry the Finished message as an encrypted handshake message. But the spec
> is a bit ambiguous as to whether this stream zero frame shall be carried as
> "Client Clear Text" or "1-RTT Data".
>
> I would much prefer 1-RTT data, because of repetition handling. If we
> imposed Client Clear Text, and the packet is lost, the stream zero frame
> will have to be retransmitted again as client clear text. That means
> interleaving clear text data and encrypted data within a single set of
> sequence number, and I am convinced that that can be abused to carry some
> kind of denial of service.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/785>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oT5HMe2FR9zNWo44cYAme93ZWPjDks5skUDRgaJpZM4PeKN8>
> .
>

-- 
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/785#issuecomment-330922993

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Sep 2017 18:45:28 +0000 (UTC)

Sure. But the look at the transport. Client packet #3 is Client Clear Text. Client packet #4 is 1RTT. Then #5 is Client clear text, repeat. #6 is 1 RTT. #7 is a fake Client Clear Text. #7 is real 1 RTT Data, but gets ignore because of duplicate SN. Etc.

-- 
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/785#issuecomment-330944944

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Sep 2017 18:48:41 +0000 (UTC)

Then look at this extract from the QUIC TLS draft:

> Important:
>     Until the handshake is reported as complete, the connection and key exchange are not properly 
> authenticated at the server. Even though 1-RTT keys are available to a server after receiving the first 
> handshake messages from a client, the server cannot consider the client to be authenticated until it 
> receives and validates the client’s Finished message.
>    The requirement for the server to wait for the client Finished message creates a dependency on that 
> message being delivered. A client can avoid the potential for head-of-line blocking that this implies by 
> sending a copy of the STREAM frame that carries the Finished message in multiple packets. This 
> enables immediate server processing for those packets. 

Howdo you do that if you cannot send the Finshed in 1-RTT packets?

-- 
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/785#issuecomment-330945860

---

From: ekr <[email-masked]>
Date: Wed, 20 Sep 2017 20:08:58 +0000 (UTC)

"Sure. But the look at the transport. Client packet #3 is Client Clear Text. Client packet #4 is 1RTT. Then #5 is Client clear text, repeat. #6 is 1 RTT. #7 is a fake Client Clear Text. #7 is real 1 RTT Data, but gets ignore because of duplicate SN. Etc."

This just seems like another DoS injection attack, which is properly solved by having a connection ID authentication tag on the cleartext packets.

The draft text you cite is just wrong.

-- 
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/785#issuecomment-330966063

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 05:18:34 +0000 (UTC)

It's not "just wrong".  The client can send multiple Client Cleartext packets. 

This goes back to an unfinished discussion we were having about including Finished (which has to be unencrypted for the cited reasons) in the same packet as 1-RTT data.  We don't have the Cleartext+Ciphertext packet that would allow that though.

-- 
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/785#issuecomment-331779462

---

From: ekr <[email-masked]>
Date: Mon, 25 Sep 2017 06:41:38 +0000 (UTC)

The text I think is wrong is "This enables immediate server processing for those packets." What is that supposed to mean? As you note above, the packets currently have to only contain Finished, so there's nothing to immediately process

-- 
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/785#issuecomment-331790345

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 07:39:22 +0000 (UTC)

OK, I agree with that.  Maybe we can get back to talking about putting encrypted data in the same packet again so that it can be made correct.

-- 
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/785#issuecomment-331801213

---

From: Christian Huitema <[email-masked]>
Date: Mon, 25 Sep 2017 08:16:44 +0000 (UTC)

There are two different issues. One is a problem of efficiency, carrying Finished (or a copy) in the same UDP packet as the first application data frames. The other is an issue of DOS resilience, knowing when to start just ignoring any non encrypted packets.

We could probably solve the efficiency issue by creating a new packet type, "clear text followed by encrypted data". I am also interested with the issue of closing the DOS opening.

-- 
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/785#issuecomment-331809243

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 09:56:22 +0000 (UTC)

I think that we would change the cleartext packet types instead.  Fewer moving parts that way.

As for the DOS opening, I get it.  You have shared keys now, but you aren't using them, at least to the extent that they are visible at the QUIC layer.  I think that more special rules might help here.  I hate special rules though.

As you say, there are two issues here.  Unfortunately, this particular issue is neither and probably should be closed.

-- 
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/785#issuecomment-331834054

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 25 Sep 2017 16:23:02 -0700

> The other is an issue of DOS resilience, knowing when to start just ignoring any non encrypted packets.

Can you start ignoring Clear Text packets, when you have successfully received client's Finished?

-- 
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/785#issuecomment-332041427

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 16:47:03 -0700

@igorlord, I think that @huitema is more concerned about the time between when the server sends its Finished and when it receives the client Finished.  At this time, the server and client share keys and could authenticate all packets, but the connection is still vulnerable to denial of service until the server receives the client Finished.

-- 
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/785#issuecomment-332045196

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 25 Sep 2017 18:06:56 -0700

@martinthomson, I think I get this concern. However, in the 3rd comment, @huitema suggests a scenario of a DoS that would not be a DoS, if the server were to ignore all Clear Text packets after receiving Client's valid Finished message.  Until the server receives Client's valid Finished message, the usual DoS concerns regarding packet injection apply.

There may be other reasons to make client's Finished encrypted after the receipt of server's Finished, but this DoS scenario is probably not it.

-- 
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/785#issuecomment-332056187

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 05:42:13 +0000 (UTC)

We already require the server to ignore cleartext packets once it has 1-RTT keys.  We could be more precise about when that comes into force.

-- 
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/785#issuecomment-332092211