Subject: [quicwg/base-drafts] Write down spoofed packet guarantees (#1347)

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 22:53:26 -0700

We agreed to this a while back, but never got around to putting the conclusions in the document.  We've done some of the work by writing down the rules for use of CONNECTION_CLOSE and TLS alerts, and the related changes, but the basic principles never got articulated.

This attempts to outline what we do to authenticate packets that we receive.

* Once the handshake is done, it's mostly simple: if the AEAD fails, drop it.
* We have a small carve-out for some types of ICMP, with some strong limitations on what that information can be used for.  @igorlord might expand the PMTU usage to cover DestUnreach, but these uses permit a very narrow range of actions.
* We also have stateless reset, which is another snowflake.
* The bulk of the text here concerns the handshake.  I've covered the two mechanisms we tie into the use of connection IDs:
** Echoing the value (the only protection we have for Version Negotiation, for instance).
** The AEAD that uses the connection ID as input.

And then it explains that our only defense against an on-path attacker is to fail to establish a connection.  I think that covers all the necessary points.

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

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

-- Commit Summary --

  * Write down spoofed packet guarantees

-- File Changes --

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

-- Patch Links --

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

---

From: janaiyengar <[email-masked]>
Date: Tue, 22 May 2018 18:18:28 -0700

janaiyengar commented on this pull request.

> @@ -4017,6 +4017,55 @@ transport to cancel a stream in response to receipt of a STOP_SENDING frame.
 
 # Security Considerations
 
+## Handshake Denial of Service
+
+As an encrypted and authenticated transport QUIC provides a range of protections
+against denial of service.  Once the cryptographic handshake is complete, QUIC
+endpoints discard packets that are not authenticated, greatly limiting the

how about "most packets", since there clearly are unauthenticated packets that are accepted.

> +endpoints discard packets that are not authenticated, greatly limiting the
+ability of an attacker to interfere with existing connections.
+
+Once a connection is established QUIC endpoints might accept some
+unauthenticated ICMP packets (see {{v4-pmtud}}), but the use of these packets is
+extremely limited.  The only other type of packet that an endpoint might accept
+is a stateless reset ({{stateless-reset}}) which relies on the token being kept
+secret until it is used.
+
+During the creation of a connection, QUIC only provides protection against
+attack from off the network path.  All QUIC packets contain proof that the
+recipient saw a preceding packet from its peer.
+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial packet and
+stateless reset, an endpoint only accepts packets that include a destination

"Except for Initial and Stateless Reset packets"

> +secret until it is used.
+
+During the creation of a connection, QUIC only provides protection against
+attack from off the network path.  All QUIC packets contain proof that the
+recipient saw a preceding packet from its peer.
+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial packet and
+stateless reset, an endpoint only accepts packets that include a destination
+connection that matches a connection ID the endpoint previously chose.  This is
+the only protection offered for Version Negotiation packets.
+
+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from the
+connection ID and salt specific to the QUIC version.  This allows endpoints to

s/the connection ID/this connection ID/

> +recipient saw a preceding packet from its peer.
+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial packet and
+stateless reset, an endpoint only accepts packets that include a destination
+connection that matches a connection ID the endpoint previously chose.  This is
+the only protection offered for Version Negotiation packets.
+
+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from the
+connection ID and salt specific to the QUIC version.  This allows endpoints to
+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw previous packets and

s/saw previous packets and understood them/saw the Initial packet and understood it/

> +the only protection offered for Version Negotiation packets.
+
+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from the
+connection ID and salt specific to the QUIC version.  This allows endpoints to
+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw previous packets and
+understood them.
+
+These protections are not intended to be effective against an attacker that is
+able to receive QUIC packets.  Such an attacker can potentially send packets
+that will be accepted by QUIC clients or servers.  This version of QUIC only
+attempts to detect this sort of attack.  Interference with the handshake is

s/only attempts to detect/attempts to only detect/

> +authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw previous packets and
+understood them.
+
+These protections are not intended to be effective against an attacker that is
+able to receive QUIC packets.  Such an attacker can potentially send packets
+that will be accepted by QUIC clients or servers.  This version of QUIC only
+attempts to detect this sort of attack.  Interference with the handshake is
+detected when the cryptographic handshake fails.  For the most part, this is a
+property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
+provide, though additional validation is required for version negotiation (see
+{{version-validation}}).
+
+Endpoints are permitted to use other methods to detect and attempt to recover
+from interference with the handshake.  For instance, if invalid packets can be
+identified then they can be discarded.  This can be complex or difficult and so

Suggested replacement for the last two sentences: "Invalid packets may be identified and discarded using other methods, but no specific method is mandated in this document."

-- 
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/1347#pullrequestreview-122403800

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 00:15:15 -0700

@martinthomson pushed 1 commit.

6cc16b6  Addressing review comments, rewording handshakey bit

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1347/files/f125a502689429e69d4a52f4ed9c9c18b185b06f..6cc16b637b240efc6bb6674a523dd7d599aaab0e

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 00:15:44 -0700

martinthomson commented on this pull request.

Thanks for the review.  I would like another for the new text about the handshake.  I took your suggestions verbatim otherwise.

 

Sure.  I was hoping that we could ultimately authenticate even those packets that don't have packet protection in some way.  For instance, by ensuring that the ICMP unreachable includes bytes from a packet we sent.  But maybe that's stretching the definition too far.

+

I've reworded this to be a little clearer (I hope).  I think that it is important to say that we don't expect endpoints to do anything other than fail when an attacker tampers with the handshake.  I realize that the lead-in to this paragraph didn't scope that properly though.  Have another 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/1347#pullrequestreview-122454973

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 May 2018 09:45:23 -0700

MikeBishop approved this pull request.

LGTM.

+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial and stateless
+reset packets, an endpoint only accepts packets that include a destination
+connection that matches a connection ID the endpoint previously chose.  This is
+the only protection offered for Version Negotiation packets.
+
+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from this
+connection ID and salt specific to the QUIC version.  This allows endpoints to
+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw the Initial packets and

packets plural?

-- 
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/1347#pullrequestreview-122672828

---

From: janaiyengar <[email-masked]>
Date: Wed, 23 May 2018 12:59:17 -0700

janaiyengar approved this pull request.

nits, but LGTM

> @@ -4035,35 +4035,35 @@ attack from off the network path.  All QUIC packets contain proof that the
 recipient saw a preceding packet from its peer.
 
 The first mechanism used is the source and destination connection IDs, which are
-required to match those set by a peer.  Except for an Initial packet and
-stateless reset, an endpoint only accepts packets that include a destination
+required to match those set by a peer.  Except for an Initial and stateless
+reset packets, an endpoint only accepts packets that include a destination

capitalize stateless reset

+

yeah, this should be "packet"

 These protections are not intended to be effective against an attacker that is
-able to receive QUIC packets.  Such an attacker can potentially send packets
-that will be accepted by QUIC clients or servers.  This version of QUIC only
-attempts to detect this sort of attack.  Interference with the handshake is
-detected when the cryptographic handshake fails.  For the most part, this is a
-property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
-provide, though additional validation is required for version negotiation (see
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC clients or

s/QUIC clients or servers/the QUIC endpoints/ ?

 These protections are not intended to be effective against an attacker that is
-able to receive QUIC packets.  Such an attacker can potentially send packets
-that will be accepted by QUIC clients or servers.  This version of QUIC only
-attempts to detect this sort of attack.  Interference with the handshake is
-detected when the cryptographic handshake fails.  For the most part, this is a
-property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
-provide, though additional validation is required for version negotiation (see
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC clients or
+servers.  This version of QUIC attempts to detect this sort of attack, but it
+expects that endpoints will fail to establish a connection rather than
+recovering.  For the most part, the cryptographic handshake protocol

I think this is fine.

-- 
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/1347#pullrequestreview-122740654

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 18:15:19 -0700

That would be a first.  It's lowercase everywhere else.

-- 
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/1347#discussion_r190441970

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 18:15:42 -0700

4722286  Fix plurals

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1347/files/6cc16b637b240efc6bb6674a523dd7d599aaab0e..47222869b758e499c4cca5ec24e5ccd395e5120f

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 18:15:58 -0700

Merged #1347.

-- 
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/1347#event-1643148627