Re: Benjamin Kaduk's Yes on draft-ietf-quic-invariants-12: (with COMMENT)

Lucas Pardue <> Wed, 06 January 2021 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 719D13A0A5E; Tue, 5 Jan 2021 19:31:37 -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 hQldG1Ukqefk; Tue, 5 Jan 2021 19:31:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319DB3A0A4C; Tue, 5 Jan 2021 19:31:35 -0800 (PST)
Received: by with SMTP id cm17so3114379edb.4; Tue, 05 Jan 2021 19:31:35 -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=Om8t/qJFOJGoUwXP/WjsP4xwwoezXa3EJmxUrU0FVvk=; b=dwUcbf7vWyNKW7O3mJ3+yeYRibPu4TCPsZEkUyw86+idCo1KkQn4v2BgK7ACbcKZrE Y+86BoWtLZ7M//X+nvQ/D+q4X4GTv+NFtNzhe+gvRjOY+MuEHKKg1tGNIl2hS4oT3hcX Ow/v0nT/Mp6+FbUzKsuH+EIHV20IegAc/q74ByHkr8IQA6OFlqQ4+1qScPCKkBqH9mKO tb+RnlKm1PsfkyzA9wSnoWnxVV+QSgoVGHvUcQCe0R2ObJRzcLsHxKnw7zIWfCmQUMW5 B0m0n5evRB1vfsy3pvXdH2XRENOvzM4k5IfmEfpV6cv4zf7YgigbfQu7eQT9TFVH6YEn 6+Ww==
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=Om8t/qJFOJGoUwXP/WjsP4xwwoezXa3EJmxUrU0FVvk=; b=rZnDuQM7PmHBEDOUp+8mNtXuBF4QHha7CsqsCzhyusp52x7uO9SzJl324PgHnAZ8c9 LldxHFpX3TkUkBGz9MeosbwHJ/RnwURK+9/xHxjikvLwoF5rl9/8O+I4nKKrep7k5Y19 PciMube3hIP/VjycNY/Xy3J5GkKJVE89ur0dpqKPsTqhkgzUl/Qey7TpvmH5vCCm0ApB 6ggvqGdbUsFiJEo4Jn573qA+fsxkFtzAP9U2qFre6caYLcLBpaFaFXoY4sUVXFikx1ru s/3+MhJ3GKMhYXV8iAP79UdK4qvycZaelePCrCgttb2nIMelInzA91ogZ1CCuqmWWlZV l7Cg==
X-Gm-Message-State: AOAM532La+a5X5DXL4XR0u0GAVIUFr+GzUcuBPpm3U8rG6nZeZ+cVTo1 Z1tZZ9aYAUkeV8C2y3OsjtvHXvpKh6gCBwIpTjo=
X-Google-Smtp-Source: ABdhPJy9ukiBFqXs9ejupQC1GvrQ8ihoGyeMG6IDvWmuNryFpDrgI8rXgWFERsXy0BSX240atN2bK5DhqLeIoq7KnuA=
X-Received: by 2002:a05:6402:139a:: with SMTP id b26mr2561409edv.47.1609903893500; Tue, 05 Jan 2021 19:31:33 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Wed, 06 Jan 2021 03:31:22 +0000
Message-ID: <>
Subject: Re: Benjamin Kaduk's Yes on draft-ietf-quic-invariants-12: (with COMMENT)
To: Benjamin Kaduk <>
Cc: The IESG <>,, WG Chairs <>, QUIC WG <>, Mark Nottingham <>
Content-Type: multipart/alternative; boundary="000000000000b1d7b305b832f5b3"
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:31:38 -0000

Hi Ben,

Thanks for the review. I've captured your comments as issues on the QUIC WG
GItHub repository. Links to each are provided as in-line responses.

On Tue, Jan 5, 2021 at 4:56 AM Benjamin Kaduk via Datatracker <> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-quic-invariants-12: 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> My PR at
> contains one editorial suggestion for this document.
> Section 5.2
> Should we call out that the short header admits a zero-length
> Destination Connection ID, implying that there will not always be a
> visible connection ID?

> Section 5.3
> In the discussion of DTLS 1.2 connection IDs we had a fair bit of
> discussion about what "opaque" means, whether any internal structure
> (e.g., when variable-length CIDs are used) must be self-delineating,
> which endpoint(s) need to know the self-delineating format, etc..  This
> was largely in the context of what data is used as input to the MAC for
> non-AEAD cipher modes (in the document as sent to the IESG by the WG,
> the party that does not know the CID structure could be convinced to
> generate a MAC using a modified CID and create a MAC value that would be
> valid for a different plaintext, leading to a change in where the
> cid_length field is placed in the input), and I don't expect the topics
> we discussed to lead to any change in the text here.  The only possible
> thing I could think of is that the field is "opaque" at the protocol
> level but may have internal structure known to the endpoint that chooses
> it (but that's arguably self-evident).

> Section 6
>    Only the most significant bit of the first byte of a Version
>    Negotiation packet has any defined value.  The remaining 7 bits,
>    labeled Unused, can be set to any value when sending and MUST be
>    ignored on receipt.
> What's the motivation behind leaving it totally free for the sender to
> pick values, as opposed to recommending or mandating that the bits be
> set to zero?
>    Version Negotiation packets do not use integrity or confidentiality
>    protection.  Specific QUIC versions might include protocol elements
>    that allow endpoints to detect modification or corruption in the set
>    of supported versions.
> Are these protocol elements expected to be in the version negotiation
> packet or elsewhere?
>    randomly selected by a client.  Echoing both connection IDs gives
>    clients some assurance that the server received the packet and that
>    the Version Negotiation packet was not generated by an off-path
>    attacker.
> (I agree with Martin D about the terminology question here and in
> Section 7, which is the location he remarked upon.)

> Section 7
>    The Version Negotiation packet described in this document is not
>    integrity-protected; it only has modest protection against insertion
>    by off-path attackers.  An endpoint MUST authenticate the contents of
>    a Version Negotiation packet if it attempts a different QUIC version
>    as a result.
> Can we give some indication of how this authentication might be done?

> Appendix A
>    *  The Version field in a QUIC long header is the same in both
>       directions
> (I note that this implicitly assumes there are only two directions.  We do
> explicitly assume there are only two parties involved, so perhaps this
> is acceptable.)

On behalf of QUIC WG Chairs