Subject: Re: [quicwg/base-drafts] Adding section on packet protection rules (#336)

From: ianswett <[email-masked]>
Date: Wed, 08 Mar 2017 13:03:53 -0800

ianswett commented on this pull request.

> @@ -1438,6 +1438,51 @@ actual exponent is one-less than the explicit exponent, and the value represents
 to 0xFFFF.

+### ACK Frames and Packet Protection
+
+ACK frames that acknowledge protected packets MUST be carried in a packet that
+has an equivalent or greater level of packet protection.
+
+Packets that are protected with 1-RTT keys MUST be acknowledged in packets that
+are also protected with 1-RTT keys.
+
+A packet that is not protected and claims to acknowledge a packet number that
+was sent with packet protection is not valid.  An unprotected packet that
+carries acknowledgments for protected packets MUST be discarded in its entirety.

In practice, discarding previously processed frames in a packet once an invalid ack is discovered is somewhat difficult.  I think it's the right suggestion, but I worry it won't be implemented correctly.

> +are also protected with 1-RTT keys.
+
+A packet that is not protected and claims to acknowledge a packet number that
+was sent with packet protection is not valid.  An unprotected packet that
+carries acknowledgments for protected packets MUST be discarded in its entirety.
+
+Packets that a client sends with 0-RTT packet protection MUST be acknowledged by
+the server in packets protected by 1-RTT keys.  This can mean that the client is
+unable to use these acknowledgments if the server cryptographic handshake
+messages are delayed or lost.  Note that the same limitation applies to other
+data sent by the server protected by the 1-RTT keys.
+
+Unprotected packets, such as those that carry the initial cryptographic
+handshake messages, MAY be acknowledged in unprotected packets.  Unprotected
+packets are vulnerable to falsification or modification.  Unprotected packets
+can be acknowledged along with protected packets in cases where the peer has

You're implying that the unprotected packets are acknowledged along with protected packets in a protected packet, but I think it'd be clearer to say "...along with protected packets in a protected packet."

> +
+Packets that a client sends with 0-RTT packet protection MUST be acknowledged by
+the server in packets protected by 1-RTT keys.  This can mean that the client is
+unable to use these acknowledgments if the server cryptographic handshake
+messages are delayed or lost.  Note that the same limitation applies to other
+data sent by the server protected by the 1-RTT keys.
+
+Unprotected packets, such as those that carry the initial cryptographic
+handshake messages, MAY be acknowledged in unprotected packets.  Unprotected
+packets are vulnerable to falsification or modification.  Unprotected packets
+can be acknowledged along with protected packets in cases where the peer has
+packet protection keys.
+
+An endpoint SHOULD acknowledge packets containing cryptographic handshake
+messages in the next unprotected packet that it sends, unless it is able to
+acknowledge those packets in later packets.  Those later packets might be

I still find the end of this sentence confusing ", unless it is able to acknowledge those packets in later packets."?  

"...unless it is able to acknowledge those packets in later packets protected by 1-RTT keys." would be much better.

> +messages are delayed or lost.  Note that the same limitation applies to other
+data sent by the server protected by the 1-RTT keys.
+
+Unprotected packets, such as those that carry the initial cryptographic
+handshake messages, MAY be acknowledged in unprotected packets.  Unprotected
+packets are vulnerable to falsification or modification.  Unprotected packets
+can be acknowledged along with protected packets in cases where the peer has
+packet protection keys.
+
+An endpoint SHOULD acknowledge packets containing cryptographic handshake
+messages in the next unprotected packet that it sends, unless it is able to
+acknowledge those packets in later packets.  Those later packets might be
+protected by 1-RTT keys.  At the completion of the cryptographic handshake, both
+peers send unprotected packets containing cryptographic handshake messages
+followed by packets protected by 1-RTT keys.  An endpoint can acknowledge the
+unprotected packets in a protected packet, because the peer has access to 1-RTT

This seems redundant to the sentence in the last paragraph talking about acking unprotected and protected packets together.  If you're going to keep it, maybe change can to SHOULD?

> +messages in the next unprotected packet that it sends, unless it is able to
+acknowledge those packets in later packets.  Those later packets might be
+protected by 1-RTT keys.  At the completion of the cryptographic handshake, both
+peers send unprotected packets containing cryptographic handshake messages
+followed by packets protected by 1-RTT keys.  An endpoint can acknowledge the
+unprotected packets in a protected packet, because the peer has access to 1-RTT
+packet protection keys.
+
+For instance, a server acknowledges a TLS ClientHello in the packet that carries
+the TLS ServerHello; similarly, a client can acknowledge a TLS HelloRetryRequest
+in the packet containing a second TLS ClientHello.  The complete set of server
+handshake messages (TLS ServerHello through to Finished) might be acknowledged
+by a client in protected packets, because it is certain that the server is able
+to decipher the packet.
+
+It is critical to not protect packets containing acknowledgements for handshake

This paragraph is mostly redundant to the other 0RTT paragraph above.

-- 
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/336#pullrequestreview-25880942

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Mar 2017 15:29:17 -0800

martinthomson commented on this pull request.

 to 0xFFFF.

That was the only thing that made me hesitate to even write this down.  Let's see how things go.  If people find themselves violating this rule, then we will need to come up with some better rules.  In practice, I think that the only thing that needs to happen is that the STREAM frames don't get passed along to the next layer.  That should be easy-ish to ensure.

-- 
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/336#discussion_r105052280

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Mar 2017 15:32:27 -0800

Removed.

-- 
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/336#discussion_r105052748

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Mar 2017 15:32:34 -0800

Yep, willdo.

-- 
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/336#discussion_r105052772

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Mar 2017 15:33:57 -0800

Merged #336.

-- 
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/336#event-992277052