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

Mike Bishop <notifications@github.com> Mon, 29 July 2019 14:47 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 1C141120133 for <quic-issues@ietfa.amsl.com>; Mon, 29 Jul 2019 07:47:58 -0700 (PDT)
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 r-ddi4ZCyWSo for <quic-issues@ietfa.amsl.com>; Mon, 29 Jul 2019 07:47:55 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5395120127 for <quic-issues@ietf.org>; Mon, 29 Jul 2019 07:47:55 -0700 (PDT)
Date: Mon, 29 Jul 2019 07:47:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1564411674; bh=IEA3TsqGQjDdQgQ9H+AKhnhMejkTmBOAOFK0UIYSm1k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uw2bJDrtCYKgvOL0Za1Fxd1dNKJmMf4tNZL5v8l5Kk8ht4Zm2EwrSndM6RnQldqOP 5te/Zqmv0lffM/+PeKe+MBUMIrTKB4SA+1OKJSmbNv2kBlqNTMoyhE4PiIeuy+1Mlj lYupFFS6LH2dlTdz4UH9pVjrTZnF6eKjJZkyY8g0=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2XYXWJHRIL6IDY3SN3JQ4ZVEVBNHHBYGSUE4@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/267821344@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 appendix (#2925)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d3f071ab99fe_69b53f7e394cd960548a4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/SOmyLHsIEG5GRqsNX5HscPc-Kjo>
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: Mon, 29 Jul 2019 14:47:58 -0000

MikeBishop approved this pull request.



> @@ -5753,13 +5753,184 @@ DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
    return candidate_pn
 ~~~
 
+# Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.  In
+this appendix, we provide an informal description of the desired security
+properties as an aid to implementors and to help guide protocol analysis.
+
+We cover properties of the handshake, general transport, and migration
+separately.

...and perhaps file an issue for that other use of "we."

> +
+An on-path attacker is present between the QUIC client and server, and an
+endpoint is required to send packets through this attacker to establish
+connectivity on a given path.
+
+An on-path attacker can:
+
+- Inspect packets
+- Modify unencrypted packet headers
+- Inject new packets
+- Delay packets
+- Drop packets
+
+An on-path attacker cannot:
+
+- Modify encrypted packet payloads

Well, they can, but the packets will no longer be accepted as valid, which is part of this threat model and mitigation.  Also, you don't discuss the unencrypted, but authenticated, portions of the headers.  Perhaps you should frame the capabilities in terms of what they can do to authenticated portions of the packet, and note that the payload is both encrypted *and* authenticated?

> +or other methods.
+
+2. An on-path attacker can prevent migration to a new path for which the
+attacker is also on-path by causing path validation to fail on the new path.
+
+3. An on-path attacker cannot prevent a client from migrating to a path for
+which the attacker is not on-path.
+
+4. An on-path attacker can reduce the throughput of a connection by delaying
+packets or dropping them.
+
+
+### Off-Path Attacker
+
+An off-path attacker is not directly on the path between the QUIC client and
+server, but is able to obtain copies of all packets sent between the client and

Perhaps change this to "may be able to obtain copies of some or all packets sent between the client and the server"?  Certainly there are subclasses of off-path attackers who see no traffic (inject-only) or who get only a partial view (e.g. eavesdropping on only one direction, one path, etc.).

> +- Delay packets
+- Drop packets
+
+An off-path attacker can, however, modify packets that it has observed and
+inject them back into the network, potentially with spoofed source and
+destination addresses.
+
+For the purposes of this discussion, we assume 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, the 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.
+
+We also assume that the attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an

Pick "the" or "an" here.  Jumping back and forth is throwing me; if there's a pattern, I'm not able to intuit it.

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