Subject: [quicwg/base-drafts] Ben Kaduk's Transport Comment 13 (#4620)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 17:08:05 -0800

@kaduk said:

Section 7.5

> > Once the handshake completes, if an endpoint is unable to buffer all
> > data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
> > CRYPTO frames received in the future, or it MAY close the connection
> > with a CRYPTO_BUFFER_EXCEEDED error code.  [...]
> 
> How future-proof is this?  NewSessionTicket is "safe" to discard in that
> doing so has no negative consequences for the current connection (it may
> indicate that previously received tickets have been invalidated, but
> that is also fairly benign and can happen for other reasons), but in
> general post-handshake CRYPTO frames are not constrained in what TLS
> messages they can carry, including any TLS messages defined in the
> future.  I am not sure that we can effectively require all future TLS
> post-handshake messages to be safe to discard.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 17:47:00 -0800

For context, this point was a little contentious, but the working group did have agreement on this text.  I would be opposed to changing in.

In defense of this, the use of TLS in QUIC is only really dependent on the handshake and NST.  And NST is very much discretionary.  If a new TLS feature arrives that requires ongoing communication at the TLS layer and QUIC depends on that, the only effect of this requirement is that that feature cannot also be used in QUIC without QUIC-layer signaling.  That's not particularly onerous in my opinion.

-- 
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/4620#issuecomment-755830485

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jan 2021 13:30:21 -0800

It's also worth noting that "and all future CRYPTO frames" is intended to guard against exactly this issue.  If we drop something, we've lost any context it might have for interpreting whatever came after, so we can't safely act on anything ever again.  If a new message is created that requires a response, our failure to respond might cause the connection to close; as Martin says, that just implies it's not supported with QUIC unless you build some extra machinery.

-- 
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/4620#issuecomment-757007149

---

From: ianswett <[email-masked]>
Date: Fri, 08 Jan 2021 15:03:31 -0800

I agree with Martin and Mike.  This was the consensus approach of the WG, and it's not perfect for every possible future scenario, but it does work.

-- 
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/4620#issuecomment-757040332

---

From: kaduk <[email-masked]>
Date: Sat, 09 Jan 2021 22:04:30 -0800

I agree with basically all the comments; my only question is whether "nor particularly onerous" applies to requiring a QUIC implementation to know and notice if/when the TLS stack it uses adds support for a new TLS extension [that happens to have the particular/bizarre attributes required to get into this situation in the first place] and turns that extension on by default.  We do in practice require some strong coordination between QUIC and TLS, but i don't know whether that will translate into ongoing strong coordination or the TLS stack will be free to add features unrelated to QUIC that might trigger this scenario.  I also don't have any proposed alternatives (we can't exactly give guidance of "confirm that all TLS extensions your stack supports are consistent with QUIC"), so I expect this is going to close with no change and we will just have some small latent risk.

-- 
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/4620#issuecomment-757423307

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 20:55:57 -0800

Accepting that risk seems OK.

-- 
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/4620#issuecomment-758400001

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 20:55:57 -0800

Closed #4620.

-- 
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/4620#event-4193985450