Re: Benjamin Kaduk's No Objection on draft-ietf-quic-qpack-20: (with COMMENT)

Lucas Pardue <> Thu, 21 January 2021 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54E343A0D55; Thu, 21 Jan 2021 06:24:39 -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 GEEnl3BIlFKC; Thu, 21 Jan 2021 06:24:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4E453A0D4A; Thu, 21 Jan 2021 06:24:36 -0800 (PST)
Received: by with SMTP id kg20so2368388ejc.4; Thu, 21 Jan 2021 06:24:36 -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=axyabRrLr/929KKEPDp/gl+NR9At0K23cVJWt/Bw54Q=; b=AgNo62C8/7kf1wRBwMUCTgtx8NC0cCh21isZn/fid08nGu/lu3sTc8EggyLW2cfpEC xJ5F7nWuC2ap5LVbe3VyCiiAsJWFyjk8IGswzPJ2YalLTxvpZWEKnkOOfuY3y+i+fUEk 6nf3twf55zgXnl7SnT8zYq/z5GEfI0UGY0RE4nEUbUaJvOWiVganTGpzcHuY8Vqj1BB5 07ZXDE9JiILXGLMWIr0JY6GwmAjNn47r36M10kA4FF57VtUFcLxHo4bTAQDlppeoVMD0 6Eq+PyKSbV/HUYzLmaCHQs4wwlrdDVpKqRmI0m+5Do1TL/Y4tatvp8bc9poTK/051kTO 7T0A==
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=axyabRrLr/929KKEPDp/gl+NR9At0K23cVJWt/Bw54Q=; b=jkyOgj7fBsYJESXZ8sb7fyKFN1BeuvsHGgJt+MmyNsCNfg/866akibMiN3HVkz32J2 LGVJltzI2FGWpIVUpR2QVhgQRqSlD8TiwxzGHS74uJVzNgKtmLyb7acs41Egi8bkY2Y7 sRio6ELT1R9EgVdGaCrZOZVfC6y8JhKXJRU4sb+2Knej4Yo9fYHmITlPAOIyh4ERf9CX KrvebxOGWhcsm1ralRjMiJwQtdhdqSYQcwD54lBjBD6uSk9zf+pHVDFNl690sh9dxHld R0jyUK2kAqR9/acuEpv3adX9GYPMjwyWo8cVGIIDw9JESaYgpxf76EFtb6VZEA3Kwi8r 41iw==
X-Gm-Message-State: AOAM5329U5PzbIZDPVmkh+lcyRBW3em0GEG/sbdvCkwnBxGJUF/jK+hN jiPJVLFlBJdBAYJi++5zwrsnU+LQXVV0OztglWc=
X-Google-Smtp-Source: ABdhPJxHCsYNT34GxZuxpi7RnIqC04Iiic4IDEz/bl38Ysssg+vULHDFyuSDgC/t9gD75yDzqIm4okD9WEl7dmflxY8=
X-Received: by 2002:a17:906:1db2:: with SMTP id u18mr9652193ejh.440.1611239075246; Thu, 21 Jan 2021 06:24:35 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 21 Jan 2021 14:24:23 +0000
Message-ID: <>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-quic-qpack-20: (with COMMENT)
To: Benjamin Kaduk <>
Cc: The IESG <>,, WG Chairs <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000ba76fd05b969d4f2"
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: Thu, 21 Jan 2021 14:24:40 -0000

Hi Ben,

Thanks for the review. I've created GitHub issue(s) to track each comment
on the QUIC WG repository, see the URL(s) in line.

On Wed, Jan 20, 2021 at 11:38 PM Benjamin Kaduk via Datatracker <> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-quic-qpack-20: No Objection
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for another well-written document!
> I put up some editorial suggestions at
> Section
> Figure 1 might benefit from an explicit indication of which direction is
> higher (or lower) absolute index.

> Section 7.1.2
> The mitigation technique of segregating the dynamic table by entity
> constructing the message seems to inherently require the encoder to have
> direct knowledge of the entity on whose behalf it is constructing a
> message.  For the other mitigation technique we present (of always using
> string literals for sensitive values), we include the 'N' bit to allow
> this attribute to be propagated through intermediaries.  However, I
> think that in scenarios where multiple intermediaries are involved, in
> the later steps in the intermediary chain the encoder will not
> necessarily have knowledge of which entity created a given message, and
> thus could inadvertently merge compression contexts that the original
> encoder had specifically kept separate.  The preconditions necessary for
> this to enable an attack seem rare, with one of the originating entities
> having access to observe the transport layer in a location several hops
> removed, so it doesn't really seem worth attempting to add a technical
> mitigation.  It would probably be worth documenting the risk, though.

> Section 8.1
> (nit) In the prose we refer to the setting names with a "SETTINGS_" prefix.
> Blindly adding that to the table looks like it would blow out the column
> count for the plaintext output, though, so I didn't put that in my
> editorial PR.

> Appendix A
> (nit) At least the plaintext output might benefit from a disclaimer
> about line wraps in the 'Value' column being display artifacts.

> Appendix B
> I worked through the examples.  The presentation format is quite nice, and
> I appreciate all the detailed breakdowns!
> However, we show the dynamic table as being 1-indexed, but I'm pretty
> sure the prose says it should be 0-indexed.  We do it consistently, at
> least, and toss some extra '1's into the math to make the numbers work
> out, but since the static table is by definition 0-indexed, it's a bit
> weird to show the dynamic table as 1-indexed.
> Additionally, I think that B.5 is an exception to the "we do it
> consistently" -- while the 81... dynamic insert with relative index 1
> does refer to the indicated custom-key field, that would be absolute
> index 3 in the 1-indexed presentation we give (though it would be
> absolute index 2 if 0-indexed, if I'm getting this right).

> Appendix C
> It might be worth a brief mention of the API contracts for (e.g.) the
> encode*() functions.  The second argument of encodeInteger() as "the
> byte value used to fill in the bits of the first byte that are not
> consumed by the trailing N-prefix integer" is particularly hard to infer
> (if it's even the correct inference).

On behalf of QUIC WG Chairs