Re: [quicwg/base-drafts] Add initial threat model to security considerations (#2925)

Martin Thomson <> Tue, 21 January 2020 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14120120071 for <>; Mon, 20 Jan 2020 22:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOZOBrKjYdvz for <>; Mon, 20 Jan 2020 22:05:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02A5D12006E for <>; Mon, 20 Jan 2020 22:05:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 39923960240 for <>; Mon, 20 Jan 2020 22:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579586734; bh=fNBCSdWDWyPkHJ89hqodIHU+PRBlaAmbchURgqHc5ko=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SVNyR8lbDB2G+5/YWUT59syLS1hC19zJJt/BZfZFyCnH6z/F4X6gH+bH2mv0Gx18v fyMdDIb+2ZHV0vyriA55YgyFC9vTWKxfp6OZvQadhElq0aG2Ajr8q5S8F3GfTj2DDx RgdDhWBGD/xQ8E8rpa2B/T/T6mKqZLuxAOy4GppM=
Date: Mon, 20 Jan 2020 22:05:34 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2925/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add initial threat model to security considerations (#2925)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e2694ae2a331_71e23fba928cd96c127883"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2020 06:05:41 -0000

martinthomson approved this pull request.

Reviewing the amended stuff.  All goodness, though I have a suggestion or two.

I think that @janaiyengar promised to take another look at this, but for me I'm getting tired of staring at this.  I want to merge this very soon.

> +
+#### Server-Side DoS
+Computing the server's first flight for a full handshake is potentially
+expensive, requiring both a signature and a key exchange computation.  In order
+to prevent computational DoS attacks, QUIC incorporates a cheap token exchange
+mechanism which allows servers to validate a client's IP address prior to doing
+any expensive computations at the cost of a single round trip.  After a
+successful handshake, servers can issue new tokens to a client which will allow
+new connection establishment without incurring this cost.
+#### On-Path Handshake Termination
+An on-path attacker can force the QUIC handshake to fail by replacing either the
+client or server Initial messages with invalid messages.  An off-path attacker
+can also mount this attack by racing the Initials.  Once valid Initial messages

As I said elsewhere, this could be simplied to:

> An on-path or off-path attacker can force the QUIC handshake to fail by replacing or racing Initial packets.  Once valid Initial packets [...]

Note: "packet" and not "message".

> +
+Attackers are additionally categorized as either on-path attackers or off-path
+attackers; see Section 3.5 of {{?RFC3552}}.  An on-path attacker can read,
+modify, or remove any packet it observes such that it no longer reaches its
+destination, while an off-path attacker observes the packets, but cannot prevent
+the original packet from reaching its intended destination.  An off-path
+attacker can also transmit arbitrary packets.
+Properties of the handshake, protected packets, and connection migration are
+considered separately.
+### Handshake {#handshake-properties}
+The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
+cryptographic properties described in {{?RFC8446}}; Appendix E.1.

cryptographic properties described in {{?TLS13=RFC8446}}; Appendix E.1.

> +
+### Handshake {#handshake-properties}
+The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
+cryptographic properties described in {{?RFC8446}}; Appendix E.1.
+In addition to those properties, the QUIC handshake is intended to provide some
+defense against DoS attacks on the handshake, as described below.
+#### Anti-Amplification
+Because the QUIC handshake can occur without a transport-level round-trip, the
+QUIC server's first flight may be sent to a client whose address it cannot
+validate.  This flight may be long and therefore potentially allows the server
+to be used as a DoS reflector/amplifier.  The mechanisms described in
+{{validate-handshake}} restrict the amplification to a factor of three.

Maybe instead:

> Address validation ({{address-validation}}) is used to verify that an entity that claims a given address is able to receive packets at that address.  Address validation limits amplification attack targets to addresses for which an attacker is either on-path or off-path.
> Prior to validation, endpoints are limited in what they are able to send.  During the handshake, a server cannot send more than three times the data it receives; clients that initiate new connections or migrate to a new network path are limited to [um, I can't find a concrete limit in the document].

> +protection ensures that valid packets are only generated by endpoints which
+possess the key material established during the handshake; see {{handshake}} and
+{{handshake-properties}}.  Similarly, any active attacker that observes QUIC
+packets and attempts to insert new data or modify existing data in those packets
+should not be able to generate packets deemed valid by the receiving endpoint.
+A spoofing attack, in which an active attacker rewrites unprotected parts of a
+QUIC packet that it forwards or injects, such as the source or destination
+address, is only effective if the attacker can forward packets to the original
+endpoint.  Packet protection ensures that the packet payloads can only be
+processed by the endpoints that completed the handshake, and invalid QUIC
+packets are ignored by those endpoints.
+An attacker can also modify the boundaries between QUIC packets and UDP
+datagrams, causing multiple packets to be coalesced into a single datagram, or
+splitting coalesced packets into multiple datagrams.  Such modification has no

splitting coalesced packets into multiple datagrams.  Aside from datagrams containing Initial packets, which require padding, modification has no

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: