Subject: [quicwg/base-drafts] Forbid Handshake key discarding (#3121)

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Oct 2019 16:29:07 -0700

After many iterations of solutions to this problem, we have decided to
first forbid discard.  We would like to have a concrete discard point,
but we couldn&#39;t agree on one that was provably safe.

If we can come up with a mechanism for discarding earlier, or a signal
that comes earlier than the end of the connection, we will first
carefully look at it, but we might accept further changes.

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

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

-- Commit Summary --

  * Forbid Handshake key discarding

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Oct 2019 18:51:34 -0700

marten-seemann 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/3121#pullrequestreview-303630014

---

From: MikkelFJ <[email-masked]>
Date: Thu, 17 Oct 2019 22:13:41 -0700

It would be helpful with a bit of context on the deadlock problem in the document. Sitting on handshake keys without making use of them will not fix the problem.

-- 
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/3121#issuecomment-543510266

---

From: MikkelFJ <[email-masked]>
Date: Thu, 17 Oct 2019 22:18:09 -0700

More specifically: since we have multiple packet number spaces, it is highly practical to replace the early handshake handler with a handler that only deals with post handshake packets. But such a handler will not work if it must still deal with handshake packets. That is a big architectural problem.

Me complaining won't make the deadlock go away, obviously, but the current situation is not very agreeable.

-- 
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/3121#issuecomment-543511594

---

From: Nick Banks <[email-masked]>
Date: Fri, 18 Oct 2019 08:24:11 -0700

I also find it hard to understand why we must keep the handshake keys (and therefor the corresponding packet space) forever, and that there is no other way to solve this problem.

-- 
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/3121#issuecomment-543795796

---

From: ianswett <[email-masked]>
Date: Fri, 18 Oct 2019 15:21:28 -0700

ianswett approved this pull request.

One suggestion, but I think this is what we agreed to.

> @@ -760,14 +760,8 @@ and ignoring any outstanding Initial packets.
 
 ### Discarding Handshake Keys
 
-An endpoint MUST NOT discard its handshake keys until the TLS handshake is
-confirmed ({{handshake-confirmed}}).  An endpoint SHOULD discard its handshake
-keys as soon as it has confirmed the handshake.  Most application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to discard their handshake keys promptly.  Endpoints that do
-not have reason to send immediately after completing the handshake MAY send
-ack-eliciting frames, such as PING, which will cause the handshake to be
-confirmed when they are acknowledged.
+An endpoint MUST NOT discard its handshake keys.  Discarding Handshake keys too
+early can lead to deadlock conditions.

```suggestion
early can lead to the peer never receiving an acknowledgement for Handshake data.
```

-- 
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/3121#pullrequestreview-304162061

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 18:43:32 -0700

@martinthomson pushed 1 commit.

844fcff850afbf98c758ccd9080e5d0f6c8b88f1  Explain moar

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3121/files/e686f9ee4b806a918db1231a7bf5b7c96a621826..844fcff850afbf98c758ccd9080e5d0f6c8b88f1

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 18:47:31 -0700

I would very much like to replace this text with something better.  But we were given an impossible set of requirements.  A strong preference was expressed for not having an explicit mechanism for driving toward a state where both peers can agree to drop keys.  All our efforts to find implicit signals have been shown to fail.  As a result, while we can drive handshakes to a completed state, because we rely on lazy signals to drive them to a confirmed state, we don't get to drop handshake 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/3121#issuecomment-544775860

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 11:49:06 -0700

While I share everyone's dismay, discussion about whether this is the right technical decision belongs on the issue, not the PR.  See you on #2863.

-- 
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/3121#issuecomment-545584377