Re: Martin Duke's Yes on draft-ietf-quic-tls-33: (with COMMENT)

Martin Thomson <mt@lowentropy.net> Wed, 23 December 2020 00:44 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A443A1362 for <quic@ietfa.amsl.com>; Tue, 22 Dec 2020 16:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=CaqUOn51; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CLPtozIA
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 rFraSbtuxe5r for <quic@ietfa.amsl.com>; Tue, 22 Dec 2020 16:44:00 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF2D3A1354 for <quic@ietf.org>; Tue, 22 Dec 2020 16:44:00 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5494B5C00AA for <quic@ietf.org>; Tue, 22 Dec 2020 19:43:59 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 22 Dec 2020 19:43:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=tY6FrcAPeJnLs3b5jPCJQfqgBQeTTAe aXDvjTJq+cS8=; b=CaqUOn51EFicGpm5Vd4Ivz36TkCMKWjaKNgmWNxS2B7vaJH ubYp4bo4hZo2fXBfrVquF+e4OHh7Zvw9raqRPO4Nh3fL4CjrlwZeosM0OTFde/6g e5JRFnX9hDcCHXTA30hBoJPaTEotAg54WD4He0W2puL9o6g7+8O7RqLvKyERoGuL ct8RX7ObwMQFXzqx5pZVvuuTSLOXJYVnU7EijxEiFsWZi4KzBIfV2vyZd5tWdl6T UawApKI93GMb/61lmI2Z0yiKx5CsnA1jNPkRK5WrDWs0mnzD2pZkrxE6bB8U9CCs 41KgaEUKGJDJgIb+ceInG9lCTxtz62Fq2HvlNzQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tY6Frc APeJnLs3b5jPCJQfqgBQeTTAeaXDvjTJq+cS8=; b=CLPtozIA65EPaL26lM2vQC xoVuxZoiFSIbVRe29ZG8/8iwsq7VnoUslue4dGXJwcz8UlzgBi4EoOry/2yEnVya QNn2pGVpIIiwbpcrZQFlNFS7fMovavxz2FECqqlxc9Jhnx5WRQ1dMjPLnnP1L93c MInHnOnhciIwdoW6UYQeJvoy4GMgPe0FLCQq2dz5nNxmh4jz6ul8smfAjRI78rws 4HXiWHPXFJ/WLm10AzD7Ar7dahgStDfJ4e2TkstMmB1lFqimn/beZVGbYSYZZkU3 /XIprKv35O2s7yYvT4uz0Lq/cfYJjGOqV80uX6YHlxZHiTZyngj5wzO2iUgiC96g ==
X-ME-Sender: <xms:z5LiXxvkEqvMNU2RWU78qB68bR34qJCs0o9bLAnUHztFSLKEHI_ySA> <xme:z5LiX6d91cr2T3WPgTIDdIGpY32wxWdGHsxHOgvSnxWV_x1lY2VKIVnIJ2-OyUFSz owzWO6WA0ujE1QLJDQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddthedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpedtgefhkeegfffhteefje ekveefteehheelgeehheevleefteefieekfefgjedvgeenucffohhmrghinhepghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:z5LiX0ziHsshijUk7SaLXFXTYTWS-OqfoVeEdDAUApmRWyTFcKGSIA> <xmx:z5LiX4MOagaJBSim77SQZXYQipaDHMJmwibTNn6Fh0jIiqfAdtZkiw> <xmx:z5LiXx-kOTu3m2Ub1i61zIyh6NOURutZOINqgOYYfmrBMHlRNzoepA> <xmx:z5LiX0KXUxIYJ5a96ZbqaRztsfeh2aY4wHnWpNmuzIV5w_WxyGzYaA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D9B12016C; Tue, 22 Dec 2020 19:43:59 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <cbda1762-2a11-4d5b-91d2-b81ae5cb4359@www.fastmail.com>
In-Reply-To: <160867913882.9107.11037319310588558127@ietfa.amsl.com>
References: <160867913882.9107.11037319310588558127@ietfa.amsl.com>
Date: Wed, 23 Dec 2020 11:43:39 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Martin Duke's Yes on draft-ietf-quic-tls-33: (with COMMENT)
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/q3X-8Wadfc1Q1-7Wtu2UkiG6FdM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2020 00:44:02 -0000

Lucas seems to have the magic touch with creating issues, so I'll stick to pull requests and emails.

On Wed, Dec 23, 2020, at 10:18, Martin Duke via Datatracker wrote:
> - The third-to-last paragraph of Sec 4.1.3 implies that the transport
> parameters are not delivered until the handshake is complete. In 8.2 it says
> that the TPs are "available" but "not fully trusted" before completion. The
> latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a
> SETTINGS frame) without any indication of the client transport parameters. I
> would suggest a clarification in 4.1.3 and letting the language in 8.2 stand.

I've opened https://github.com/quicwg/base-drafts/pull/4463 for this.  I've done less in 4.1.3, but more in 8.2 than you suggest.  I hope this helps.
 
> - 5.8 says the ODCID field "mitigates an off-path attacker's ability to inject
> a Retry".
> 
> First, in quic-transport you defined an off-path attacker (21.1) as someone who
> can observe but not alter packets. I don't think that's what you mean here, so
> please use another a term here or explicitly define what you mean in this
> document. Come to think of it, there are some inconsistent usages of this term
> in quic-transport as well (14.2.1,17.2.1, 17.2.2 )

This is an excellent point.  My intuition regarding "off-path" matches that of RFC 3552, but the definition QUIC uses is subtly different.  That means that some of our usage was inconsistent with our own definitions.

Rather than try to find new terminology, which would be very disruptive, we went through and did the following things:
1. Clarify that off-path is slightly different than was is written in RFC 3552 (it is consistent only to the extent that 3552 contemplates the off-path attacker forcing its way on-path).
2. Tighten the language and make it clearer that the off-path attacker is only able to copy and inject packets.
3. Remove uses of off-path that were inconsistent with this definition in both -transport and -tls.  There weren't many to fix.

Changes are here: https://github.com/quicwg/base-drafts/pull/4462

> Secondly, it is not clear to me what protection this offers beyond the DCID
> field in the actual Retry Packet (which corresponds to the SCID of the Initial).

The SCID of the Initial might be empty (it is in many cases), which doesn't provide enough entropy to prevent spoofing of Retry otherwise.