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

Martin Thomson <notifications@github.com> Wed, 22 January 2020 00:58 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 C87291200C4 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jan 2020 16:58:05 -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 faQ0NmJGRhi0 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jan 2020 16:58:03 -0800 (PST)
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 2894D1200C3 for <quic-issues@ietf.org>; Tue, 21 Jan 2020 16:58:03 -0800 (PST)
Received: from github-lowworker-9bcb4a1.ac4-iad.github.net (github-lowworker-9bcb4a1.ac4-iad.github.net [10.52.25.84]) by smtp.github.com (Postfix) with ESMTP id 833786A0022 for <quic-issues@ietf.org>; Tue, 21 Jan 2020 16:58:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579654682; bh=LIsHwkIrET2D1g4w29iLg4boBezToJ2IzE3qLWgghGg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NRHLfawlNOODrlhAODhz4rrCQ/HWMMGxUwse34zsJ25yNjbcXKapcTtgOGIKoigRk Cdvs3S0ewLbiCj/1y2s5x2LEUqI8DZdQlFFHSUqw8br0DNKBL4dsd2wdmbpzyxBAZ4 muDLE515l7XVCQtv7q4S8j69G5TO4pHs7gFtZoLs=
Date: Tue, 21 Jan 2020 16:58:02 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZY3BC5F7CKERSBBBN4GTIJVEVBNHHBYGSUE4@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/346283685@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_5e279e1a6ed72_64613ffbcc2cd96025161b"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/h5OrDwpAIEW1ixLVaYcN9BwChBI>
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: Wed, 22 Jan 2020 00:58:06 -0000

martinthomson commented on this pull request.

Just so everyone is clear on what is happening here, I've made a few changes and landed this.  This is obviously a lot of text and it could benefit from more review, but the editors all agreed that it would better to make incremental changes rather than continue to maintain our oldest open PR further.

> +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.

Without further elaboration, I have to agree.  

Separately, I think it was Antoine who made some (good) points about authenticating connection IDs more thoroughly that we might want to consider.  Separately though (reminds self to open an issue).

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

Key exchange is correct (the key exchange depends on the message exchange, but it's the key exchange that matters here).

> +
+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"

It's first use would seem to work well enough to be definitional.  I'm happy with this as it is.

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