Subject: [quicwg/base-drafts] Idempotency and replay (#4393)

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2020 20:52:25 -0800

The text in [Section 5.6 of the TLS draft](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-use-of-0-rtt-keys) is wrong.  Subtly, but distinctly.

This seems fairly direct about idempotency being the benchmark.  However, that is not consistent with [RFC 8470](https://tools.ietf.org/html/rfc8470#section-4), which goes further than idempotency and strongly recommends that only safe methods be used.

This will result in a substantive change.  @britram should be aware that this will also result in applicability doc changes also.

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Nov 2020 15:51:40 -0800

I don't disagree on the change for QUIC, but is there an avenue to fix this in TLS?  I'm slightly uncomfortable differing from TLS in this regard, even if we're "right."

-- 
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/4393#issuecomment-733309789

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 24 Nov 2020 19:41:41 -0800

I see @MikeBishop's point, but it seems to me that this is a stronger constraint than TLS, not a weaker one. In that sense, I would argue that it is not at odds with TLS, even though it is different.

-- 
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/4393#issuecomment-733443548

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 25 Nov 2020 02:58:20 -0800

I think @MikeBishop makes a good point here, and I'm not sure if QUIC-TLS is more stringent than TLS 1.3.

Taking a quick look of appendix E.5 of RFC 8446, I notice the following differences:
* TLS 1.3 states that stacks "MUST NOT enable 0-RTT unless _specifically requested_ by the application", whereas the PR #4394 states that stacks "MUST only use 0-RTT for application data that is _permitted_ by the application." We might consider the requirements as being different.
* TLS 1.3 states that the stack "MUST NOT automatically resend 0-RTT data if it is rejected by the server unless instructed by the application" (appendix E.5). I'm not sure if we have something similar in QUIC-TLS.

I haven't done a thorough check, but these differences might be concerning.

-- 
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/4393#issuecomment-733634021

---

From: Nick Banks <[email-masked]>
Date: Wed, 25 Nov 2020 08:31:59 -0800

> TLS 1.3 states that stacks "MUST NOT automatically resend 0-RTT data if it is rejected by the server unless instructed by the application." I'm not sure if we have something similar in QUIC-TLS.

As far as I know we have no such restriction/requirements in QUIC-TLS. In MsQuic we allow the app to control this behavior. When informed of 0-RTT rejection, they have the option of aborting any stream data they had queued (and allowed the use of 0-RTT). This would result in the corresponding STREAM_RESET/STOP_SENDING frames being sent to the peer in 1-RTT. I the app doesn't abort, then we'd immediately retransmit the stream data in a 1-RTT packet the first chance we got. Should we not be doing this? If not, how else would/could we handle this?

-- 
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/4393#issuecomment-733814421

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 30 Nov 2020 04:10:44 -0800

@nibanks I think you are correct in pointing out that we do not have such a restriction in QUIC-TLS. That in turn means that QUIC is deviating from TLS 1.3 that mandates the application to "instruct" if data sent in 0-RTT should be replayed. I think that having such a requirement in QUIC is difficult, because QUIC stacks might retransmit data sent in 0-RTT packets using 1-RTT packets.

I think that leads to the conclusion that QUIC has to specify it's own "replay safety," because it cannot have have all the "out of abundance of caution" MUSTs that TLS 1.3 have. At the end of the day, I think #4394 is fine as it is.

-- 
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/4393#issuecomment-735748080