Subject: [quicwg/base-drafts] Mitigate amplification attacks during handshake (#1090)

From: Mike Bishop <[email-masked]>
Date: Thu, 01 Feb 2018 00:54:16 +0000 (UTC)

Lifted out of #1082 and building on #1086, this attempts to mitigate a potential amplification in which an attacker finds a server with a very large certificate, spoofs a source address, and then uses the server's handshake to generate traffic.  It limits the server from sending more than three Handshake packets to an unvalidated source address.  Suggested ways of validating are Retry packets and PATH_CHALLENGE.

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

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

-- Commit Summary --

  * Use PATH_CHALLENGE and PATH_RESPONSE frames.
  * Mitigate amplification attacks during handshake

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 16:58:52 -0800

martinthomson requested changes on this pull request.

> @@ -650,8 +650,18 @@ described in {{packet-numbers}}.  The client increments the packet number from
 its previous packet by one for each Handshake packet that it sends (which might
 be an Initial, 0-RTT Protected, or Handshake packet).
 
-The payload of this packet contains STREAM frames and could contain PADDING and
-ACK frames.
+Servers MUST NOT send more than three Handshake packets without receiving a
+packet from a verified source address.  If the server expects to generate more
+than three Handshake packets in response to an Initial packet, it SHOULD include
+a PATH_CHALLENGE frame in each Handshake packet that it sends.  After receiving
+at least one valid PATH_RESPONSE frame in a Handshake packet, the server can

You don't need to say where the frame is in this sentence.  You do need to change the TLS doc to permit the use of these frames in Handshake packets.

> @@ -650,8 +650,18 @@ described in {{packet-numbers}}.  The client increments the packet number from
 its previous packet by one for each Handshake packet that it sends (which might
 be an Initial, 0-RTT Protected, or Handshake packet).
 
-The payload of this packet contains STREAM frames and could contain PADDING and
-ACK frames.
+Servers MUST NOT send more than three Handshake packets without receiving a
+packet from a verified source address.  If the server expects to generate more
+than three Handshake packets in response to an Initial packet, it SHOULD include
+a PATH_CHALLENGE frame in each Handshake packet that it sends.  After receiving
+at least one valid PATH_RESPONSE frame in a Handshake packet, the server can
+send its remaining Handshake packets.  (Servers MAY instead perform address

s/MAY/can and remove the parentheses.

> @@ -650,8 +650,18 @@ described in {{packet-numbers}}.  The client increments the packet number from
 its previous packet by one for each Handshake packet that it sends (which might
 be an Initial, 0-RTT Protected, or Handshake packet).
 
-The payload of this packet contains STREAM frames and could contain PADDING and
-ACK frames.
+Servers MUST NOT send more than three Handshake packets without receiving a
+packet from a verified source address.  If the server expects to generate more

You should probably explain that the server is only able to verify a client source address after receiving an address validation token or the final cryptographic handshake message from the client (in TLS, we can tell earlier, but that's not a transport-level guarantee).

-- 
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/1090#pullrequestreview-93138129