Subject: [quicwg/base-drafts] Revise text on ACK frames prior to handshake completion (#719)

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Aug 2017 18:32:50 -0700

This extensively used language like "protected ACK frames", which is incorrect.
I fixed that here, recognizing that more extensive fixes are probably needed.

I also just made the observation that the server might acknowledge 0-RTT, but
the client might be unable to read those ACK frames, which closes #221.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Revise text on ACK frames prior to handshake completion

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Thu, 10 Aug 2017 02:34:19 +0000 (UTC)

ianswett commented on this pull request.

A few suggestions to make the wording stronger.

> -ISSUE:
-
-: What about 0-RTT data?  Should we allow acknowledgment of 0-RTT with
-  unprotected frames?  If we don't, then 0-RTT data will be unacknowledged until
-  the handshake completes.  This isn't a problem if the handshake completes
-  without loss, but it could mean that 0-RTT stalls when a handshake packet
-  disappears for any reason.
-
-An endpoint SHOULD use data from unprotected or 0-RTT-protected `ACK` frames
-only during the initial handshake and while they have insufficient information
-from 1-RTT-protected `ACK` frames.  Once sufficient information has been
-obtained from protected messages, information obtained from less reliable
-sources can be discarded.
+Endpoints MUST NOT use an `ACK` frame in an unprotected packet to acknowledge
+packets that were protected by 0-RTT or 1-RTT keys.  An endpoint MUST ignore an
+`ACK` frame in an unprotected packet if it claims to acknowledge data that was

So the endpoint needs to ignore the entire ack frame if any packets acknowledged were protected?

> +packets that were protected by 0-RTT or 1-RTT keys.  An endpoint MUST ignore an
+`ACK` frame in an unprotected packet if it claims to acknowledge data that was
+sent in a protected packet.  Such an acknowledgement can only serve as a denial
+of service, since an endpoint that can read protected data is always able to
+send protected data.
+
+Note:
+
+: 0-RTT data can be acknowledged by the server as it receives it, but any
+  packets containing acknowledgments of 0-RTT data cannot have packet protection
+  removed by the client until the entire server handshake is received by the
+  client.
+
+An endpoint SHOULD use data from `ACK` frames carried in unprotected or
+0-RTT-protected packets only during the initial handshake and while they have
+insufficient information from `ACK` frames in 1-RTT-protected packets.  Once

I'd like to make this stronger if possible.  How about "only before they have received an 'ACK' frame in a 1-RTT protected packet.  Once they have received an ack frame in a 1-RTT protected packet, all ack frames with less protection MUST be ignored."

> -
-An endpoint SHOULD use data from unprotected or 0-RTT-protected `ACK` frames
-only during the initial handshake and while they have insufficient information
-from 1-RTT-protected `ACK` frames.  Once sufficient information has been
-obtained from protected messages, information obtained from less reliable
-sources can be discarded.
+Endpoints MUST NOT use an `ACK` frame in an unprotected packet to acknowledge
+packets that were protected by 0-RTT or 1-RTT keys.  An endpoint MUST ignore an
+`ACK` frame in an unprotected packet if it claims to acknowledge data that was
+sent in a protected packet.  Such an acknowledgement can only serve as a denial
+of service, since an endpoint that can read protected data is always able to
+send protected data.
+
+Note:
+
+: 0-RTT data can be acknowledged by the server as it receives it, but any

I'm not sure how this note is helpful.  The server has to send all acks either unprotected or in 1RTT packets, correct?  If so, it seems simpler to say "0-RTT data can be acknowledged by the server as it is received, but it must be send with 1-RTT protection."?

-- 
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/719#pullrequestreview-55420770

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Aug 2017 20:16:41 -0700

@martinthomson pushed 1 commit.

230589f  Strength requirement

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/719/files/c32c3788a298bdcca5d8d5f15b1e4602134febc6..230589fe68637ba7954a4c177e5bb5069900b385

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Aug 2017 20:16:45 -0700

martinthomson commented on this pull request.

-

I'm applying principles we agreed: if it looks like trash, throw it out.  This ensures that a disruptive presence has to guess everything correctly in order for their disruption to be successful.  I'd say throw out the entire packet, but that might not be possible (other stuff might have been processed, and we don't want to ask implementations to rewind their TLS state machine, for instance). 

The point here is to highlight a problem with this requirement, not to restate the requirement to protect ACK frames.  The problem is that the server handshake might not be complete from the perspective of the client.  That leads to the client not having 1-RTT keys.  Which then leads to the client being unable to read those ACK frames.

I think that we could be even stronger.  See revision.

-- 
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/719#discussion_r132355400

---

From: ianswett <[email-masked]>
Date: Thu, 10 Aug 2017 03:44:56 +0000 (UTC)

Thanks for the improvements, some followup suggestions.

-

Another option is to close the connection if we think this is something we want to enforce.  I think I'd prefer that, since partially consumed packets creates edge cases I don't want to consider if I don't need to.

Ah, makes sense.  How about "will not" instead of "cannot" and possibly a mention of why, such as the server sending acks with 1RTT keys and the client not having them?  I thought you were telling the client what it must do, not describing the issue.

-- 
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/719#pullrequestreview-55428121

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Aug 2017 04:11:51 +0000 (UTC)

d19b7f8  Harder again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/719/files/230589fe68637ba7954a4c177e5bb5069900b385..d19b7f8a11f08062e726258ea5389127ecd13628

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Aug 2017 21:13:17 -0700

-

That would work, and would be consistent with the other principle (don't do too much about interference prior to agreeing on keys).

"will not" implies lack of will, whereas cannot is correct - it's impossible (or a cryptographically-enforced equivalent thereof).  I will explain why though.

-- 
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/719#discussion_r132359764

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Aug 2017 04:14:16 +0000 (UTC)

This is no longer strictly editorial.  @janaiyengar, can you take a quick look?

-- 
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/719#issuecomment-321445850

---

From: ianswett <[email-masked]>
Date: Fri, 11 Aug 2017 03:47:57 +0000 (UTC)

ianswett approved this pull request.

Thanks for the changes, I'm happy with 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/pull/719#pullrequestreview-55713282

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 04:11:26 +0000 (UTC)

Merged #719.

-- 
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/719#event-1204170544