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

ianswett <notifications@github.com> Tue, 21 January 2020 17:17 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB245120044 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jan 2020 09:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfpzqHuD4yd3 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jan 2020 09:17:40 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2D71201A3 for <quic-issues@ietf.org>; Tue, 21 Jan 2020 09:17:39 -0800 (PST)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 508ED661E9C for <quic-issues@ietf.org>; Tue, 21 Jan 2020 09:17:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579627059; bh=PQdjW4+27yvftYQYwCNSOYVDa4lgPsfTXwGhOVOBXhU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1p+3ReYqSJCMkbBUog9N0QbFr7OxDPfChHuuV7+lrDrD01RHJSNQslk0fe7n7dBy+ KqsyZLB3X7iERdj1qyEea6vEbecvlAKxSsbmn3BoLASoQw8APXfJSYH4eyHnYu1y8+ Frm0Nqpz7B9qQq1NWQ+wPpVby0a/vYgRSJzBPm5Q=
Date: Tue, 21 Jan 2020 09:17:39 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2QY5P6FODRC3RE2HV4GRSLHEVBNHHBYGSUE4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2925/review/346016818@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2925@github.com>
References: <quicwg/base-drafts/pull/2925@github.com>
Subject: Re: [quicwg/base-drafts] Add initial threat model to security considerations (#2925)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e2732333ffc5_73383ff726ccd9601092a2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Y_gPWbatd8YauEOAvAnhD5zCoJ0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2020 17:17:47 -0000

ianswett approved this pull request.

Some suggestions, but nothing concerning, so LG.

> +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
+have been exchanged, the remaining handshake messages are protected with the
+handshake keys and an on-path attacker cannot force handshake failure, though
+they can produce a handshake timeout by dropping packets.
+
+An on-path attacker can also replace the addresses of packets on either side and
+therefore cause the client or server to have an incorrect view of the remote
+addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### Parameter Negotiation
+
+The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter

nit: Is it a key exchange or message exchange?

> +addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### Parameter Negotiation
+
+The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter
+negotiation is folded into the TLS transcript and thus provides the same
+security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe
+the client's transport parameters (as long as it knows the QUIC version-specific
+salt) but cannot observe the server's transport parameters and cannot influence
+parameter negotiation.
+
+Connection IDs are unencrypted but integrity protected in all messages.  They
+are not incorporated in the TLS handshake transcript.

This is potentially misleading, since there is the original_connection_id transport param, but I'm not sure if it's worth mentioning.

> +{{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
+functional effect on a QUIC connection, although it might change the performance
+characteristics exhibited by the receiving endpoint.

@MikeBishop In terms of relying on how packets were coalesced, I don't believe there's any reliable information to be obtained, and relying on these hueristics is already prone to cause problems.  For example, there's no guarantee that a receiver buffers the currently undecryptable packets in a datagram if it can decrypt at least one packet.  So yes, we should caution against that if we don't already.

> +### Connection Migration {#migration-properties}
+
+Connection Migration ({{migration}}) provides endpoints with the ability to
+transition between IP addresses and ports on multiple paths, using one path at a
+time for transmission and receipt of non-probing frames.  Path validation
+({{migrate-validate}}) establishes that a peer is both willing and able
+to receive packets sent on a particular path.  This helps reduce the effects of
+address spoofing by limiting the number of packets sent to a spoofed address.
+
+This section describes the intended security properties of connection migration
+when under various types of DoS attacks.
+
+#### On-Path Active Attacks
+
+An attacker that can cause a packet it observes to no longer reach its intended
+destination is considered an on-path attacker.  Such an attacker generally is

generally is present is both a somewhat strong(implying >50% of the time) and quite vague statement.  Maybe this clause should be changed to: "When an attacker is present between the QUIC client and server, QUIC endpoints are required to send packets through the attacker to establish connectivity on a given path."?

> +
+An on-path attacker cannot:
+
+- Modify an authenticated portion of a packet and cause the
+ recipient to accept that packet
+
+An on-path attacker has the opportunity to modify the packets that it observes,
+however any modifications to an authenticated portion of a packet will cause it
+to be dropped by the receiving endpoint as invalid, as QUIC payloads are both
+authenticated and encrypted.
+
+In the presence of an on-path attacker, QUIC aims to provide the following
+properties:
+
+1. An on-path attacker can prevent use of a path for a QUIC connection, causing
+it to fail if it cannot migrate to a new path that does not contain the

I'm not sure it's necessary to use the word 'migrate' here.  If the handshake hasn't completed, you can't migrate yet.  If you take my suggestion, it probably makes sense to update the other bullets.

```suggestion
it to fail if it cannot use a different path that does not contain the
```

> +
+For the purposes of this discussion, it is assumed that an off-path attacker has
+the ability to observe, modify, and re-inject a packet into the network that
+will reach the destination endpoint prior to the arrival of the original packet
+observed by the attacker.  In other words, an attacker has the ability to
+consistently "win" a race with the legitimate packets between the endpoints,
+potentially causing the original packet to be ignored by the recipient.
+
+It is also assumed that an attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an
+attacker to obtain the same port for use with its traffic.
+
+In the presence of an off-path attacker, QUIC aims to provide the following
+properties:
+
+1. An off-path attacker can race packets and attempt to become a "limited"

The word race is used a few times in this section, but I don't believe it's defined and I'm not sure it's clear to everyone what it means in this context?

> +
+It is also assumed that an attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an
+attacker to obtain the same port for use with its traffic.
+
+In the presence of an off-path attacker, QUIC aims to provide the following
+properties:
+
+1. An off-path attacker can race packets and attempt to become a "limited"
+on-path attacker.
+
+2. An off-path attacker can cause path validation to succeed for forwarded
+packets with the source address listed as the off-path attacker as long as it
+can provide improved connectivity between the client and the server.
+
+3. An off-path attacker cannot cause a connection to close.

```suggestion
3. An off-path attacker cannot cause a connection to close once the handshake has completed.
```

> +
+- Delay packets so that they arrive later than packets sent on the original path
+- Drop packets
+- Modify the authenticated and encrypted portion of a packet and cause the
+ recipient to accept that packet
+
+A limited on-path attacker can only delay packets up to the point that the
+original packets arrive before the duplicate packets, meaning that it cannot
+offer routing with worse latency than the original path.  If a limited on-path
+attacker drops packets, the original copy will still arrive at the destination
+endpoint.
+
+In the presence of a limited on-path attacker, QUIC aims to provide the
+following properties:
+
+1. A limited on-path attacker cannot cause an active connection to close.

```suggestion
1. A limited on-path attacker cannot cause an established connection to close.
```

-- 
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/2925#pullrequestreview-346016818