Subject: [quicwg/base-drafts] Clarify crypto context for Connection Close (#1818)

From: martinduke <[email-masked]>
Date: Mon, 01 Oct 2018 15:17:16 -0700

Partially resolves #1786.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify crypto context for Connection Close

-- File Changes --

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

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 01 Oct 2018 15:25:43 -0700

Seems reasonable.

-- 
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/1818#issuecomment-426084735

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 01 Oct 2018 18:04:38 -0700

kazuho commented on this pull request.

> @@ -2606,6 +2606,16 @@ An endpoint sends a closing frame (CONNECTION_CLOSE or APPLICATION_CLOSE) to
 terminate the connection immediately.  Any closing frame causes all streams to
 immediately become closed; open streams can be assumed to be implicitly reset.
 
+If the endpoint has successfully decrypted a 1-RTT packet from its peer, it
+SHOULD send CONNECTION_CLOSE in a 1-RTT packet. If not, and it has received a

This does not work if the client decides to abort the handshake in response to the server's Handshake messages, because the server's messages typically end with NewSessionTicket carried by a 1-RTT packet but the server cannot decrypt a 1-RTT packet from client until it receives ClientFinished.

IMO, we should state that an endpoint SHOULD send CONNECTION_CLOSE using a Handshake packet until either of the following to condition is met: a) it knows that the peer can decrypt a 1-RTT packet, b) it drops the Handshake keys based on the timer.

Other than that, the PR looks good to me.

-- 
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/1818#pullrequestreview-160538484

---

From: ianswett <[email-masked]>
Date: Mon, 01 Oct 2018 18:50:23 -0700

ianswett commented on this pull request.

How about "the handshake is complete and it knows the peer can decrypt a 1-RTT packet."?

-- 
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/1818#discussion_r221806848

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 01 Oct 2018 19:13:38 -0700

That works for me, though I would prefer dropping the former (i.e. "handshake is complete") because it's confusing; IIUC we do not have a definition of when the handshake becomes complete, and we could argue in various ways on when it becomes complete. Actually, the latter condition (i.e. "knows the peer can decrypt a 1-RTT packet") is when the handshake is _known_ to have been complete.

-- 
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/1818#discussion_r221809572

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 01 Oct 2018 19:20:58 -0700

FWIW, a client "knows that the peer can decrypt a 1-RTT packet" when it receives the first ACK for a 1-RTT packet it has sent. A server knows that when it obtains the 1-RTT read key from the TLS stack (i.e. when a ClientFinished received from the client is processed without an error).

We might want to clarify 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/1818#discussion_r221810280

---

From: martinduke <[email-masked]>
Date: Fri, 05 Oct 2018 15:24:28 -0700

@martinduke pushed 1 commit.

ccbaf4c  Addressed Kazuho's issue

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 05 Oct 2018 15:29:31 -0700

Is this sufficient? The peer might ignore handshake level packets when ACK'ing 1-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/pull/1818#issuecomment-427515602

---

From: martinduke <[email-masked]>
Date: Fri, 05 Oct 2018 16:12:00 -0700

@mikkelfj It shouldn't. If it decrypts the packet, it MUST tear it down. Worst case, it's already tossed the keys, which seems a bit premature in this context. But we could suggest sending in both contexts.

-- 
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/1818#issuecomment-427522070

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 05 Oct 2018 20:03:19 -0700

@mikkelfj I _think_ what the PR says is sufficient, because it an endpoint is expected to hold the Handshake key for 3 RTO after all transmission using the key has been complete. Quoting from Section 4.9 of the TLS draft:
> After all CRYPTO frames for a given encryption level have been sent and all expected CRYPTO frames received, and all the corresponding acknowledgments have been received or sent, an endpoint starts a timer. For 0-RTT keys, which do not carry CRYPTO frames, this timer starts when the first packets protected with 1-RTT are sent or received. To limit the effect of packet loss around a change in keys, endpoints MUST retain packet protection keys for that encryption level for at least three times the current Retransmission Timeout (RTO) interval as defined in [QUIC-RECOVERY]. Retaining keys for this interval allows packets containing CRYPTO or ACK frames at that encryption level to be sent if packets are determined to be lost or new packets require acknowledgment.

-- 
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/1818#issuecomment-427540971

---

From: martinduke <[email-masked]>
Date: Fri, 19 Oct 2018 15:53:16 -0700

595680a  Merge branch 'master' into patch-21

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1818/files/ccbaf4c20040baa61547bbe8532da5b0243271e2..595680a05b06e2ab2c2fa24725e696af0ce05600

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Oct 2018 16:27:24 -0700

Merged #1818 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/1818#event-1916883581