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

Lucas Pardue <> Tue, 22 December 2020 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0259E3A11D8; Tue, 22 Dec 2020 10:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xrpYsdBdmFc2; Tue, 22 Dec 2020 10:15:23 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9EF13A11D6; Tue, 22 Dec 2020 10:15:22 -0800 (PST)
Received: by with SMTP id j16so13838616edr.0; Tue, 22 Dec 2020 10:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2BLp9ZVKImTiYJsRQGYf9Djia5vGtlEceVA6TQJr1E0=; b=nuekZQXiEehPQ0HT5nBa2O8LBiJmAy/9nheQ5aFtJ7Gla1Q6N4Kwjf8AHE0i2JXDST aNbNLhmqHnM2RxgulbU7MKsL0n2ZrpwyaIZU1r6UESlTk98fRoB04GCoDTAHAVkvDeSw gtuUuA8OgfJOzLzGTGNr+PReIrS1wnBC9Wm4/jNU7isnVGM0PCSCEkSOfPxTFV9+ntgB I6EmAgLd5rozEzECwDxPie5Dz7ElclrtBGrLdQPuqND3Q25TutM01vW+ZmBV1JNnNa8u 0elgnsitVF6tiUf+nFDZD23r1Edozi0JhV/UnbstY3t5eQTXJDzTfrV+KEeKiu2W4Hln +IKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2BLp9ZVKImTiYJsRQGYf9Djia5vGtlEceVA6TQJr1E0=; b=rjW3VI3i0/vosvoPATOecayCsqDmGN15ikQGctOejpHi6O97KhRljrwnAdA3MIsZJ1 xqsdlSfC/noB+oiqMhOBquAw/UPHUi0OVK99n5/zpvpAbBSw32AawNEI0V+lO9wY78yw LaMhQWaGkwxxKsTc4ZCCbjIPL7tONw3Cb45DUXcWIstuhU5QBuBPSIT62pLb4mUUE+9+ 6eGZGVVQRhFMK/d+sNlHKH3f+WWsE9yvzvmqGwgMNwPe7SYVFb/bRztvEuOahimR2TDg Al26EzkfALCH3xRbpJAwB1fuIGln7+Chn7fTcb+7MV8tc0YkZjDPM51oQV11Pp4yIiEU N43Q==
X-Gm-Message-State: AOAM531TCWI8uddvjGXE2fXdk5aCBg6au5Hx7RE6FxffeMulQY8kYY/a GWqiJi2VVsUspf5FaeAJPSLfU6zpwlPDPTJo4AU=
X-Google-Smtp-Source: ABdhPJwzV5kQA3zXxb3XoFckygw9MWpa/nYaBvfcOQHG27guAQiCx44SD3IM6XFf+meptcrHTLZ1gdqdc+hq7w3bEBM=
X-Received: by 2002:a05:6402:c4:: with SMTP id i4mr21394326edu.152.1608660920881; Tue, 22 Dec 2020 10:15:20 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 22 Dec 2020 18:15:08 +0000
Message-ID: <>
Subject: Re: Martin Duke's Yes on draft-ietf-quic-transport-33: (with COMMENT)
To: Martin Duke <>
Cc: The IESG <>,, WG Chairs <>, QUIC WG <>, Lars Eggert <>
Content-Type: multipart/alternative; boundary="000000000000c0d95f05b7118efd"
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: Tue, 22 Dec 2020 18:15:25 -0000

Hi Martin,

Thanks for the comments. I've captured each comment as a new issue on the
QUIC WG base-drafts Github repository and tagged you in each one. The
document editors will follow up on each issue and may create Pull Requests
if needs be. See in-line response for more details. We'll be tracking all
IESG comments on the Transport document under

On Tue, Dec 22, 2020 at 12:09 AM Martin Duke via Datatracker <> wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-quic-transport-33: Yes
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I'm proud of the IETF for producing this document. I have a few minor
> comments
> and a bunch of nits.:
> 17.2.1 I believe it is correct that there will be no negative consequences
> from
> not having Retry-like integrity protection on VN packets. But I ask the
> editors
> to take one more careful look at it, as the VN format is one of those
> things we
> really cannot fix later.

> 21.13 "This means that client-controlled fields, such as the initial
> Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be
> used
> by themselves to make routing decisions." There was a lot of discussion in
> the
> QUIC-LB design team about whether this was an attack to be worried about or
> not, and we came down in favor of "not".
> More importantly, I don't see how this is practical advice. If we're to use
> Retry SCIDs to route subsequent packets, then load balancers have to use
> the
> DCID of Initials. Without validating the token, which most LBs will not do,
> they have no way of distinguishing between attacker-generated DCIDs with a
> bogus token and those that originally came from the server. One option is
> to
> simply remove this recommendation.
> Alternatively, you could leave this section unaltered and delete the bit in
> 8.1.2 about using Retry to reroute packets. In practice, keeping 21.13
> would
> require a revision of QUIC-LB to just use 4-tuple routing for long header
> packets or make it less robust for new versions.

> 22 I am unclear about the status of these registries (except the version
> registry) for new versions. QUICv2 might have entirely new frame, TP, and
> error
> registries, right? Is it worthwhile to point that out? Or that it's heavily
> discouraged, or forbidden?

> 3.1 An endpoint shouldn't "generate STREAM_DATA_BLOCKED frames" if it is
> suffering from connection flow control limits.

> 8.1.2 I am not sure what you mean by the phrase "that can be unprotected"

> 13.3 I believe MAX_STREAM_DATA retransmissions should cease in state

> 13.3 "it is not forbidden to retransmit copies of frames from lost
> packets" Is
> this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be
> copied.

> 14 "Thus, modern IPv4 and all IPv6 network paths will be able to support
> QUIC."
> Generally true, but should be qualified for the presence of arbitrary
> numbers
> of tunnels.

> 16 The CID length field is another exception to varint encoding.

17.2.2 Please include a reference for HelloRetryRequest for those unfamiliar
> with TLS.

> "A client MUST use the same cryptographic handshake message it
> included in this packet. A server MAY treat a packet that contains a
> different
> cryptographic handshake message as a connection error or discard it." If
> the
> client hello is large, the Retry Token itself might affect what part of it
> fits
> in the packet. The language here doesn't contradict that, but a naive
> server
> implementation of the server check might not catch that corner case (e.g.
> including a hash of the CHLO in the Retry token)
> [BTW the very next paragraph redundantly repeats part of this requirement].

On behalf of QUIC WG Chairs