Subject: [quicwg/base-drafts] TLS MUST NOT deliver server 1RTT Rx keys until getting Finished (#3173)

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

In #3159 it's becoming clear that some QUIC server implementations are using their 1RTT receive keys before getting CFIN, which is not supposed to happen.

IMO, there are going to be plenty of hacky QUIC implementations but only a handful of TLS implementations, especially TLS implementations that have the special APIs required for QUIC. This is the narrow waist where we should enforce good behavior.

Figure 5 of quic-tls shows that we shouldn't deliver the keys that early, but there's no normative language. I will file a PR shortly for quic-tls that imposes this requirement, so that QUIC implementations can't possibly mess this up.

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

---

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

I like that this class of problem is naturally assumed to require some sort of protocol change.  As I said on #3159, maybe those implementations can fix their bug.

#3174 is a pragmatic sort of fix that would make this an editorial issue.  I'd like that, but it sounds like there is a strong desire to go all nuclear on this.  We should discuss that, or its spectre will haunt us.

-- 
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/3173#issuecomment-548152461

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 Oct 2019 22:32:16 -0700

I think it's worth noting this, though I tend to agree with @martinthomson that we cannot write this down using an normative language because that is a requirement of TLS.

That said, I actually wonder if we can have a section discussing Implementation Pitfalls. TLS 1.3 has an appendix dedicated to that (see [RFC 8446, Appendix C](https://tools.ietf.org/html/rfc8446#appendix-C])), and it has been extremely helpful to me. I think it would be nice to have something like that in the QUIC drafts.

-- 
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/3173#issuecomment-548222995

---

From: martinduke <[email-masked]>
Date: Wed, 30 Oct 2019 22:44:08 -0700

I'm not sure of the rules here, but this requirement is on the
QUIC-specific interfaces. People already have to modify TLS to comply with
quic-tls.

On Wed, Oct 30, 2019, 10:32 PM Kazuho Oku <[email-masked]> wrote:

> I think it's worth noting this, though I tend to agree with @martinthomson
> <https://github.com/martinthomson> that we cannot write this down using
> an normative language because that is a requirement of TLS.
>
> That said, I actually wonder if we can have a section discussing
> Implementation Pitfalls. TLS 1.3 has an appendix dedicated to that (see RFC
> 8446, Appendix C <https://tools.ietf.org/html/rfc8446#appendix-C%5D>),
> and it has been extremely helpful to me. I think it would be nice to have
> something like that in the QUIC drafts.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3173?email_source=notifications&email_token=AF2EYEOEZU6V2ZTNHKZXIBDQRJUWDA5CNFSM4JG4TGM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWTQEY#issuecomment-548222995>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AF2EYEMNAQODAS2X2JFFTVLQRJUWDANCNFSM4JG4TGMQ>
> .
>

-- 
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/3173#issuecomment-548225144

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 Oct 2019 23:52:06 -0700

> I'm not sure of the rules here, but this requirement is on the QUIC-specific interfaces.

IIUC, This requirement comes from the TLS handshake protocol defined in section 4 of RFC 8446 (specifically, [section 4.4.4](https://tools.ietf.org/html/rfc8446#section-4.4.4)). TLS 1.3, DTLS 1.3, and QUIC all share the same handshake protocol.

-- 
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/3173#issuecomment-548238886

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 31 Oct 2019 06:02:22 -0700

Wouldn't this prevent the server from sending 0.5 RTT responses to 0-RTT?

-- 
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/3173#issuecomment-548363177

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 31 Oct 2019 06:09:51 -0700

Or, well, sending 0.5 RTT at all, not just for 0-RTT.

-- 
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/3173#issuecomment-548366311

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 Oct 2019 07:10:44 -0700

@ghedo Regardless of if we should use the normative language in QUIC-TLS, I think that RFC 8446, Section 4.4.4 clarifies what the requirements are, i.e.:
* do not use the 1-RTT keys until the Finished is received
* with the exception of 0-RTT
* and also with the exception of 0.5-RTT, while keeping in mind that the peer's identity or liveness has not been asserted.

-- 
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/3173#issuecomment-548393663

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 31 Oct 2019 14:59:24 +0000 (UTC)

@kazuho yeah, that makes sense thanks.

-- 
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/3173#issuecomment-548416891

---

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

@ghedo No, just the receive keys.

-- 
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/3173#issuecomment-548476378

---

From: martinduke <[email-masked]>
Date: Thu, 31 Oct 2019 17:12:09 +0000 (UTC)

@kazuho I understand that the key applicability is a general property of TLS1.3; however QUIC is the only one where the secret is actually consumed outside of TLS. quic-tls defines this interface and we have the right to impose constraints on 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/3173#issuecomment-548477221

---

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

@martinduke As said, it is not only QUIC. DTLS 1.3 also uses the TLS 1.3 handshake protocol while having a different packetization layer ("records" in TLS term).

That said, I am fine with letting the editors of the QUIC-TLS draft decide.

-- 
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/3173#issuecomment-548581491