Re: Erik Kline's Yes on draft-ietf-quic-transport-33: (with COMMENT)

Martin Thomson <> Wed, 06 January 2021 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68BC83A0BE9; Tue, 5 Jan 2021 19:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=cXRQCxO6; dkim=pass (2048-bit key) header.b=YKi8Ztzd
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zPIrNRtYo6Mz; Tue, 5 Jan 2021 19:53:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1A4F3A0BE3; Tue, 5 Jan 2021 19:53:02 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1C0AF5C01AE; Tue, 5 Jan 2021 22:53:02 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Tue, 05 Jan 2021 22:53:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=XZ3HcAcjgPKsMY7NL9UtIrWG/xVd ytgmGl8+6vF++Ig=; b=cXRQCxO6/vDXPhXkTKRLHmjWJkYzoLGBK4TG9XPg8TWX PZi3XYqX7HyVLLhLYOB/mc0XJ9b4jRTWnFwRYU/JkxixXAflOlDqC/OqQidi+Ogo 4tezBGunSQqUn4G48Q2ATk2eLw9tL1+CXSTAlmIj41kISjkzSx3qCBoUNUd2cPXZ 6hCNOkDcaEvQYlheqYo2DNSnJfcXR+7X0ROCWYT54qsEy0PAOvGkLzhfkmR7YDUY TSTkuTPQeaBoehilLjQ46pQkVPn0DkTNfqoXwh5kEQkA7iop2efpNCWVFWfnHpXJ Jj4FnRubxVwzxO5PFKo47EXZuYQuuNWYer7R/jRZYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=XZ3HcA cjgPKsMY7NL9UtIrWG/xVdytgmGl8+6vF++Ig=; b=YKi8ZtzdWJdrrDYu1pr0gC AF67qcZZ2AuDpbIwxI3MuUM3SCPIjgLNrKvOcrZv66EFzafzAycAcFihiCae0c0g XtSfS/lvFTKbZDVUUXN7WKi5/tv43shiFnSrH0EtD5x6z9j7EF087nGjEZVhcDLB i6f99DaE3BFkxBi6x2Zlam2DWQ8gCyPs3aRJX5LmqzDIpzlxZm3dBORbXweXz2dc sSGuyevc3xSCiFfBZ3nEC/7y9nMGsQv6R5TKp8+HMxR9oAMDHWtPkM6IIKi9ptzZ moCd1zzEd3F/JcN6xk5gTTsemwsfkDJBw5o2+X5RPF5G6QH+YfQXOuqH5UVAY/Nw ==
X-ME-Sender: <xms:HDT1X_uQOizUgw0HWwZfOEzkqqcZPnCrx8CkrvQsZ_8y4FdAg21uTA> <xme:HDT1XwdZiwzw4ylHEGEprQbfwYZ-MlP_y4KEKBxy_1-VKh2KOLe7p5Qj-tX_ASGnF 20nJLcSRS3wMakekV0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefkedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:HTT1XyyKJaVl87gp11l2hD6dYwa4f48x8y0yRTeLgqhs5TqY-x72DQ> <xmx:HTT1X-PIkthLYN4FzaQWAd9gvltc0sPG8_AI7Ts-YyJzTvstkUzjzw> <xmx:HTT1X_8-g167lpxmsJJ1ik2VwlFVQwAatocUpWuJR4x7qFeu16hLLw> <xmx:HjT1XyZG7pZkhT1I7yXfYvOQX5sHnMkRvuIQxrWsemwApWggdKtbAg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7FB120066; Tue, 5 Jan 2021 22:53:00 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 06 Jan 2021 14:52:40 +1100
From: Martin Thomson <>
To: Erik Kline <>, The IESG <>
Cc:, WG Chairs <>,, Lars Eggert <>
Subject: Re: Erik Kline's Yes on draft-ietf-quic-transport-33: (with COMMENT)
Content-Type: text/plain
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2021 03:53:04 -0000

Hi Erik,

Thanks for the comments.   I'll answer your questions here, since I don't think they result in document changes.  We'll take the comments to GitHub, where they can be broken down into specific actions.

On Tue, Jan 5, 2021, at 17:18, Erik Kline via Datatracker wrote:
> [ section 8.2.4 ]
> * To be clear, this document is effectively saying that it takes no position
>   on the interpretation of any ICMP errors received?  Is it up to the
>   implementer to decide if "validated" (in as much as ICMP messages can be
>   validated) Admin Prohibited messages, for example, should constitute a
>   positive confirmation of path failure?  Or is there some very specific
>   stance that should be taken ("never trust that lyin' ICMP!")?

I don't think we could reach consensus on a single policy for treatment of ICMP.  As you observe, some might regard ICMP as unreliable no matter the circumstances, others might trust but verify, and others might be happy to accept the signals without validation.  Support for RFC 4884 and larger packet samples might shift attitudes.

What I can say is that many implementations are not doing anything with ICMP, other than what the OS might automatically turn into socket errors.  That means that ICMP Unreachable can still have an effect in many stacks, but PTB doesn't enjoy the same privilege (at least to my knowledge, though I guess the OS could apply write size limits on its own, I don't know that any do).

> [ section 10.3 ]
> * Does this "datagram ends with stateless reset token" scheme mean that
>   implementations must check the output of every packet, including post
>   encryption, and take some action if a (very low probability) collision
>   occurs (meaning the output accidentally produces this 16 byte value
>   but the packet is not intended to be a stateless reset)?

In practice, the exception that follows means that you don't need to perform the check very often.  Most implementations only check when they are unable to decrypt or - more applicable to servers - unable to determine which connection is able to handle the packet.  The relevant text says:

> This comparison can be performed for every inbound datagram. Endpoints MAY skip this check if any packet from a datagram is successfully processed. However, the comparison MUST be performed when the first packet in an incoming datagram either cannot be associated with a connection, or cannot be decrypted.

Those that do check every datagram do run a risk of encountering a collision.  But it is tiny.

To take an extreme example, a server instance that receives ~2^62 packets for every connection (the maximum number any single connection can have, and far more than you can practically send), and you have a large number of connections (2^17 connections is a lot, but maybe plausible), and you check every inbound packet against every connection, the odds of collision are in the same ballpark as the odds that a dedicated and resourceful attacker might have to break encryption[1] at 2^-51 [2].

The Internet is big enough that this will likely happen, but I'm of the opinion that this risk is acceptable.  In any case, avoiding extra cycles has the effect of driving this probability right down.

[1] We allow 2^-57 probability.
[2] Well, maybe a little higher, but I'm too lazy to run the birthday paradox numbers.