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

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 20:10:54 -0800

This is - at the moment - a little redundant with text in the -tls document.  That's probably OK until we sort out where that text belongs.

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

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

-- Commit Summary --

  * Adding section on packet protection rules

-- File Changes --

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

-- Patch Links --

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 22 Feb 2017 23:29:36 -0800

janaiyengar commented on this pull request.

> @@ -1266,6 +1266,42 @@ actual exponent is one-less than the explicit exponent, and the value represents
 4096 microseconds.  Any values larger than the representable range are clamped
 to 0xFFFF.
 
+
+### ACK Frames and Packet Protection
+
+ACK frames that acknowledge protected packets MUST be carried in a packet that
+has an equivalent level of packet protection.  Functionally, this means:
+
+* Unprotected packets, such as those that carry the initial cryptographic
+  handshake messages, can be acknowledged in unprotected packets.  This has

I don't understand why this text says they "can" be acked in unprotected packets. Shouldn't we require that they MUST?

> @@ -1266,6 +1266,42 @@ actual exponent is one-less than the explicit exponent, and the value represents
 4096 microseconds.  Any values larger than the representable range are clamped
 to 0xFFFF.
 
+
+### ACK Frames and Packet Protection
+
+ACK frames that acknowledge protected packets MUST be carried in a packet that
+has an equivalent level of packet protection.  Functionally, this means:
+
+* Unprotected packets, such as those that carry the initial cryptographic
+  handshake messages, can be acknowledged in unprotected packets.  This has
+  several consequences:
+
+  * Acknowledgments for packets containing cryptographic handshake messages
+    SHOULD be included in packets carrying the next cryptographic handshake

I don't think this SHOULD is necessary at all. The receiver can just as well sent these in two packets.

> +
+ACK frames that acknowledge protected packets MUST be carried in a packet that
+has an equivalent level of packet protection.  Functionally, this means:
+
+* Unprotected packets, such as those that carry the initial cryptographic
+  handshake messages, can be acknowledged in unprotected packets.  This has
+  several consequences:
+
+  * Acknowledgments for packets containing cryptographic handshake messages
+    SHOULD be included in packets carrying the next cryptographic handshake
+    message.  For instance, a server can acknowledge 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 initial set of server handshake messages, which could span multiple
+    packets, SHOULD be acknowledged in unprotected packets even if the client

SHOULD --> MUST ?

> +    uses 0-RTT keys to protect other packets that are sent at the same time.  A
+    server might decide to reject and ignore 0-RTT data, making it unable to use
+    any acknowledgments that are protected with 0-RTT keys.
+
+* 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.  However, the same limitation applies
+  to other data sent by the server protected by the 1-RTT keys.
+
+* 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.

Should the connection be closed if this happens? 

-- 
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-23412230

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 16:20:56 -0800

@martinthomson pushed 1 commit.

29bbe2a  Restructure section to better address some of the concerns and add some explanation

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/336/files/da921328508d6a0cc0371e35f468d80b09e3c2da..29bbe2a6dc4609e390adce5ced977844f5122e54

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 18:48:14 -0800

martinthomson commented on this pull request.

+

I didn't want to insist that they be acknowledged in unprotected packets.  For instance, the client sends a Finished message unprotected, followed by a bunch of protected packets.  It should be possible to send a single protected acknowledgement for all of those packets.

+

Why send two unprotected packets when you only need to send one?

Yes.  Too many shoulds.

No, otherwise it would allow for an attacker to kill a connection.  See the Public Reset discussion.

-- 
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_r102844657

---

From: ianswett <[email-masked]>
Date: Fri, 24 Feb 2017 09:12:57 -0800

ianswett commented on this pull request.

Thanks for the clarifications.

> @@ -1266,6 +1266,53 @@ actual exponent is one-less than the explicit exponent, and the value represents
 
+
+### ACK Frames and Packet Protection
+
+ACK frames that acknowledge protected packets MUST be carried in a packet that
+has an equivalent level of packet protection.

equivalent or greater?

> +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
+packet protection keys.
+
+An endpoint SHOULD acknowledge packets containing cryptographic handshake
+messages in the next unprotected packet that is sends, unless it is able to

I don't think unprotected is necessary in this sentence.  I believe a client SHOULD acknowledge the ServerHello in the next packet it sends, even though that would be using 1RTT keys.

I'm also not sure what "unless it is able to acknowledge those packets in later packets." is attempting to say.

> +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 is 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

can acknowledge => SHOULD acknowledge?

+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 is sends, unless it is able to
+acknowledge those packets in later packets.  Those later packets might be

I'm not sure what "Those later packets might be protected by 1-RTT keys." is adding here?

> +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 use unprotected packets to acknowledge packets containing
+cryptographic handshake messages from a server, even if the client has access to

This is only true when there are no 1RTT keys, so how about "It is critical to not protect packets containing acknowledgements with 0RTT keys."  And then your last sentence explains why.

-- 
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-23761692

---

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Feb 2017 17:19:47 -0800

+

Note that we have the open issue whereby the client sends its last flight in an unprotected packet (see #337).

That calls out to the later text on acknowledgments.  For example, if the client receives the full flight of messages from the server (ServerHello..Finished), then it could send an ACK in an unprotected packet.  OR it could just acknowledge in the protected packets that it is about to send anyway.  I want the SHOULD here still because I think that timely ACKs during the handshake are hugely valuable, but we have to acknowledge that the content of the ACK is vulnerable to tampering and so implementations might prefer to protect ACKs in some cases.

-- 
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_r103124729

---

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Feb 2017 17:23:51 -0800

328b65b  Ian's suggestions.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/336/files/29bbe2a6dc4609e390adce5ced977844f5122e54..328b65bc31c12c5092e5534766ffc56a46489477

---

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Feb 2017 17:23:33 -0800

See above.

I don't think so.  I would prefer to leave this to implementations so that they can make the integrity/timeliness trade-off.  We're accepting that ACKs are sometime unprotected, and an attacker can always force an implementation (by dropping protected packets carefully), so that seems like a reasonable trade-off to leave open.

Ahh, yes, much better.

-- 
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_r103124743

---

From: ianswett <[email-masked]>
Date: Mon, 27 Feb 2017 06:11:05 -0800

+

If the concern is timeliness, why not say immediately, rather than discuss whether it's protected or unprotected?  Also, the vulnerability comes from the peer processing the unprotected ack, so as long as the peer is expected to process it, the sender of the ack doesn't gain much by waiting for 1RTT keys to ack it.

ie: "An endpoint SHOULD acknowledge packets containing cryptographic handshake messages with no ack delay, even if the 1RTT keys are not yet available." 

I wanted to put immediately, but I think it's reasonable for the client to process a 2 or 3 packet reject and then only send 1 ack, if all the packets arrive essentially at once.

-- 
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_r103212936