Subject: Re: [quicwg/base-drafts] Protected pre-handshake packets (#39)

From: ekr <[email-masked]>
Date: Sun, 08 Jan 2017 19:57:58 -0800

ekr commented on this pull request.

> -once key agreement has completed.  This means that protected messages need to be
-decrypted to determine if they are TLS handshake messages or not.  Similarly,
-`ACK` and `WINDOW_UPDATE` frames might be needed to successfully complete the
-TLS handshake.
-
-Any timestamps present in `ACK` frames MUST be ignored rather than causing a
-fatal error.  Timestamps on protected frames MAY be saved and used once the TLS
-handshake completes successfully.
-
-An endpoint MAY save the last protected `WINDOW_UPDATE` frame it receives for
-each stream and apply the values once the TLS handshake completes.  Failing
-to do this might result in temporary stalling of affected streams.
+Due to reordering and loss, 1-RTT protected packets might be received by an
+endpoint before the final TLS handshake messages are received.  These will not
+be able to be decrypted, unless the missing handshake messages are the second
+flight of handshake messages sent by the client.

This seems like it's clumsily phrased, because you state a general rule and then qualify it.

There are actually three cases here, with subcases.

1. 0-RTT packets from the client to the server.
2. 1-RTT packets from the server to the client
3. 1-RTT packets from the client to the server.
    (a) in non-PSK mode
    (b) in PSK mode.

Note that in case 3 you will be able to  decrypt and in case 3(b) you have proof of knowledge of the PSK and of the integrity of the CH, as well as of freshness, though not of the integrity of the handshake (w/o trusting AEAD instead of the handshake). What's the general principle here?

> -each stream and apply the values once the TLS handshake completes.  Failing
-to do this might result in temporary stalling of affected streams.
+Due to reordering and loss, 1-RTT protected packets might be received by an
+endpoint before the final TLS handshake messages are received.  These will not
+be able to be decrypted, unless the missing handshake messages are the second
+flight of handshake messages sent by the client.
+
+Protected packets MAY be stored and later decrypted and used once the handshake
+is complete.  If packets are processed prior to completion of the handshake, an
+attacker might use the willingness of an implementation to use these packets to
+mount attacks.
+
+Receiving and verifying the Finished message is critical in ensuring that the
+TLS handshake has completely successfully.  A server MUST NOT use 1-RTT
+protected packets from the client if its response depends on client
+authentication.  A server MAY use 1-RTT protected packets from a client prior to

I assume you mean you must not use them prior to receiving the client's finished?

> +Due to reordering and loss, 1-RTT protected packets might be received by an
+endpoint before the final TLS handshake messages are received.  These will not
+be able to be decrypted, unless the missing handshake messages are the second
+flight of handshake messages sent by the client.
+
+Protected packets MAY be stored and later decrypted and used once the handshake
+is complete.  If packets are processed prior to completion of the handshake, an
+attacker might use the willingness of an implementation to use these packets to
+mount attacks.
+
+Receiving and verifying the Finished message is critical in ensuring that the
+TLS handshake has completely successfully.  A server MUST NOT use 1-RTT
+protected packets from the client if its response depends on client
+authentication.  A server MAY use 1-RTT protected packets from a client prior to
+receiving and verifying the Finished message if it has accepted 0-RTT data and
+it treats the out-of-order packets as though they only have 0-RTT protection.

This doesn't seem quite right to me. You do know that these are fresh.

-- 
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/pull/39#pullrequestreview-15644371

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jan 2017 00:35:41 -0800

martinthomson commented on this pull request.

Yeah, I fucked this up.  I think that the observation is that the client has to buffer or discard and the server can decrypt.  But what rules can be provide the server that will be guaranteed safe?

The PSK point is interesting, but I'd rather not fall back on it.  It's a fairly lengthy string of logic: given that the CH integrity is provided by the binder, then the server can be assured that it selected a cipher suite based on correct information, which means that you can assume that the keys AND the AEAD are correct.  It's a lot to write down, I'm not sure if I want that.

Do you think it's a terrible thing if we insist that the server wait for the Finished before using these packets?  Or is the PSK thing worth the effort of carving out an exception?

Yeah, I'm going to strike that.  If we cover this, it's all down to the PSK question.

Yeah.

-- 
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/pull/39

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jan 2017 00:35:45 -0800

@martinthomson pushed 1 commit.

efde873  Rewrite based on feedback from ekr

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/39/files/32dfeab698be86939ad2b7543df54dbc9e1eab8b..efde8733a892775233a15d5f07d028d073d33b43

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jan 2017 20:28:05 -0800

8c288c2  Merge branch 'master' into protected_pre

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/39/files/efde8733a892775233a15d5f07d028d073d33b43..8c288c26755037147282aa1fb3e9a7ae27e25383