Subject: [quicwg/base-drafts] Deny 1-RTT Rx keys till finished (#3174)

From: martinduke <[email-masked]>
Date: Wed, 30 Oct 2019 09:55:39 -0700

Fix for #3173.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3174

-- Commit Summary --

  * Deny 1-RTT Rx keys till finished

-- File Changes --

    M draft-ietf-quic-tls.md (3)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3174.patch
https://github.com/quicwg/base-drafts/pull/3174.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 18:11:57 -0700

martinthomson commented on this pull request.

This seems fine, though I was a little concerned about levying requirements on TLS stacks in this way, it seems like a reasonable thing to recommend.

> @@ -504,6 +504,9 @@ client could interleave ACK frames that are protected with Handshake keys with
 0-RTT data and the server needs to process those acknowledgments in order to
 detect lost Handshake packets.
 
+A TLS implementation MUST NOT provide a 1-RTT decrypt secret to QUIC until it
+has received a Finished message from the peer.

```suggestion
the TLS handshake is complete.
```

Receiving a Finished message is not sufficient, as you have to verify it.  Also, at least in our stack, verifying the Finished is not the only condition we hold handshake completion on.  We also wait until the certificate is marked as "OK", which is an asynchronous process and so might happen after validating the 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/pull/3174#pullrequestreview-309603787

---

From: martinduke <[email-masked]>
Date: Thu, 31 Oct 2019 10:09:36 -0700

@martinduke pushed 1 commit.

e7da545640c9f2230e44d8d60284b8ecc468612f  Update draft-ietf-quic-tls.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3174/files/cac3e7ec954ad589a33e3bd005d33d7d36bfab64..e7da545640c9f2230e44d8d60284b8ecc468612f

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 Oct 2019 14:50:35 -0700

kazuho commented on this pull request.

Thank you for the PR. I agree that giving a warning to the implementors in the QUIC-TLS draft is the right choice.

I am fine with the PR aside from the editorial concern below.

+A TLS implementation MUST NOT provide a 1-RTT decrypt secret to QUIC until it
+the TLS handshake is complete.

As stated in https://github.com/quicwg/base-drafts/issues/3173#issuecomment-548222995, I do not think we should be using a normative word here, as this is a requirement in the TLS 1.3 handshake protocol (specifycally the one stated in [section 4.4.4](https://tools.ietf.org/html/rfc8446#section-4.4.4)).

QUIC is a user of the TLS handshake protocol (like DTLS 1.3), and we should not repeat what the TLS handshake protocol already requires you to do.

That said, I am fine with editors making the choice.

-- 
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/3174#pullrequestreview-310201499

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Oct 2019 15:23:03 -0700

I'm persuaded by Kazuho's argument here.  I don't think that we need the whole appendix, but a note on this might be worth adding.

-- 
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/3174#discussion_r341390149