Subject: [quicwg/base-drafts] Applications need to disable or selectively reject 0-RTT (#3138)

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 14:26:06 -0700

Closes #3136.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Applications need to disable or selectively reject 0-RTT

-- File Changes --

    M draft-ietf-quic-transport.md (2)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3138.patch
https://github.com/quicwg/base-drafts/pull/3138.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/3138

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 18:26:45 -0700

ianswett commented on this pull request.

Some more comments

> @@ -1159,7 +1159,7 @@ the operations described in this section on a QUIC connection.
 When implementing the client role, applications need to be able to:
 
 - open a connection, which begins the exchange described in {{handshake}};
-- enable 0-RTT; and
+- disable or selectively reject 0-RTT; and

A client doesn't receive 0-RTT, so how would it reject it?

The way I think of it is:
"be informed when 0-RTT keys are available."
"be informed when 1-RTT keys are available."

I don't think the client application needs to know if 0-RTT is rejected or accepted, as long as the handshake succeeds?  And applications like HTTP/3 don't want to enable 0-RTT, but only send some data with 0-RTT 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/pull/3138#pullrequestreview-306274593

---

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

martinthomson commented on this pull request.

Whoops.  Let me fix that.

-- 
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/3138#discussion_r338346761

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 18:31:42 -0700

@martinthomson pushed 1 commit.

a8c8ed1549b2915f1c51fd4ffff7a3882631f608  This is the client

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

---

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

That was silly.  I think that "enable 0-RTT *when available*" suffices.  We don't need to go into detail about 0-RTT keys or any of that mess, that's an internal concern of the transport.

For our stack, we enable 0-RTT always (you can't turn it off), and rely on applications using the handshake state to determine whether what is being sent is 0-RTT (or 0.5-RTT) or not.  If there is no 0-RTT, then attempts to create streams will fail.

-- 
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/3138#discussion_r338347580

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 18:45:58 -0700

Your implementation sound similar to ours.  But in both cases, it seems like the application doesn't care of 0-RTT succeeds or fails.  It only cares to know when 1-RTT keys are available.  But the existing text indicates the application needs to know about 0-RTT success/failure.

-- 
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/3138#discussion_r338349488

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 19:12:31 -0700

The application (protocol) definitely need to know when 0-RTT is rejected because it has to start over completely for anything that it might have already sent (that's the very next interface requirement).  However, for that to happen, it makes sense for the application to know when it was attempting 0-RTT.

Our API would satisfy this simply by allowing stream creation and writing prior to handshake completion: the application just needs to understand that writing before handshake completion means that you are attempting 0-RTT.  Our TLS stack has a different API, because of backward compatibility: you have to explicitly turn on 0-RTT.  Either approach works fine, except that QUIC doesn't need to concern itself as much with backward compatibility.

-- 
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/3138#discussion_r338353738

---

From: ianswett <[email-masked]>
Date: Fri, 25 Oct 2019 09:30:50 -0700

Makes sense, I forgot 0-RTT wasn't automatically re-sent in IETF QUIC.

-- 
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/3138#discussion_r339138086

---

From: ianswett <[email-masked]>
Date: Fri, 25 Oct 2019 09:31:06 -0700

ianswett approved this pull request.

-- 
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/3138#pullrequestreview-307318753

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Oct 2019 08:51:20 -0700

MikeBishop approved this pull request.

-- 
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/3138#pullrequestreview-308625578

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 15:48:54 -0700

Merged #3138 into master.

-- 
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/3138#event-2754070242