Re: Experience of a new implementor with the latest working drafts

Lucas Pardue <> Sat, 10 April 2021 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE79B3A1383 for <>; Sat, 10 Apr 2021 09:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 im14F6EJOm_B for <>; Sat, 10 Apr 2021 09:26:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62CB63A1382 for <>; Sat, 10 Apr 2021 09:26:25 -0700 (PDT)
Received: by with SMTP id e7so10005153edu.10 for <>; Sat, 10 Apr 2021 09:26:25 -0700 (PDT)
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=KMCoCWx2FFfdaNgzMAL5WP+psHzAz6r+2ej2Ruc/WBU=; b=gnVN+Teuc4EW+S8P5EteD3Th9A2u0fruQ5tNuzgZQ/A3iuvsMznvIuvCrDIP1w0k8l 37GnfDImTZ/lvF618O0sUBWLiW86l+jTXuvncZ6x96BfZpb9orCXAV7RYZznK77qCUgx +t090jsdVRaQkCCm3AYX9z5P4f1sZmkXFA23nYgNxJP1Tm1pv5bZJaUobINqGo6jqSy7 BFK13PR2clUdV9OTHmKZTb7tmMFhOiW49Jb4o9w0XcjocmfMCRpGPVe0+HZdK25fztfO He3rp4ryfjqULRBl9hgm9BEzSRyUwC4RdRfoHhCSejGeWmta6gisRQ17DtcDZcnCYL6+ +tEQ==
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=KMCoCWx2FFfdaNgzMAL5WP+psHzAz6r+2ej2Ruc/WBU=; b=uMVLdpzzfbRwVQM+lCX3V1Zv33ZebZO9ilc4xTXE5C/3extW3/eWSu8HRmgjGeVGxE aRwQRtO9U3yk/nLv8LtInOWSu1flJxVPcqA9n7gPQvkz9PLBxDBcVbcV9BFdfRNQtDaF b2kg1+l41bixDgkgdM4oDJe14eYYerfXiZBRe7emuNAk/nrEZ1uHtYju1Tbjid7Gou/O x9Nv7fPcn25S2qWrCznnV99VpyuM8SXDUzEpAC4BZrDJ78GR6NqKEq0qSyNLUUtkh7NK h8R7rkhIYd7Oro2UQcyS1GBL4B950beCab6IRBOCociZNXgjedsbDt9knGu2uwsC6n0G mQqg==
X-Gm-Message-State: AOAM531Q6haGNMj2yWpaH2ATz0mG1f78lmL96gktlC9HJ7fa+87uNAI0 wGnA4SApnN75ObET7ya4HCrxgez+ITTdSQf1KeQ=
X-Google-Smtp-Source: ABdhPJwidv2Ei+l00Xhnc7je2atXpxuILex3XuHWq7NZNBctcAD9zyywb6hb+Pr8coKyjz/1ZnyX0K6m9fFXV9QUuec=
X-Received: by 2002:aa7:db95:: with SMTP id u21mr22373053edt.152.1618071981928; Sat, 10 Apr 2021 09:26:21 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Sat, 10 Apr 2021 17:26:10 +0100
Message-ID: <>
Subject: Re: Experience of a new implementor with the latest working drafts
To: JP Sugarbroad <>
Cc: QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000b432de05bfa0bdb4"
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: Sat, 10 Apr 2021 16:26:28 -0000

Hi there,

Firstly thanks for taking the time to try out QUIC and to write your
experience as a new implementator.

QUIC is an always-secure transport protocol. QUIC connections start with a
combined transport and cryptography handshake. This provides advantages but
also introduces some complexity to bootstrapping an implementation,
certainly in contrast to contemporary protocols like TCP or UDP.

Although QUIC conceptually supports different cryptographic handshakes, QUIC
version 1 has chosen a design based on the TLS 1.3 handshake. These two are
entwined and need to be understood in tandem to get an implementation

I appreciate some of the specific feedback you've provided. QUIC is a
complex protocol and the current document organisation is our attempt to
balance the needs of several constituencies that rely on the QUIC
specifications. The QUIC documents have now passed WGLC, IETF last call and
IESG review. Any changes risk invalidating prior review comments or
established consensus. I'll let the editors respond if they think any of
your observations might be addressed with trivial editorial changes. As a
gauge: additional cross reference are likely trivial, moving text or adding
further examples is non-trivial.

That said, gathering feedback such as yours is useful in the longer term. A
future document revision of QUIC v1 may be able to incorporate
improvements. Or we might take suggestions as a signal that the community
believes it would benefit from a new document like an implementers
introdixtion/guide. So again thanks for your time, even if we can't
directly address things today.

QUIC WG co-chair

On Sat, 10 Apr 2021, 12:09 JP Sugarbroad, <> wrote:

> So I decided to poke my head in and answer the question "what does a bare
> minimum compliant HTTP/3 client look like?". The answer so far has been...
> slow going.
> I started with "how do I construct the first packet", but the information
> I needed was scattered. I'm used to being able to pull partial information
> from an RFC without reading the whole thing, so I skipped around a lot:
> Do you send an Initial packet or a Handshake packet? Well, section 5 says
> "Each connection starts with a handshake phase", so maybe Handshake packet.
> But then 5.2.2 says "If the packet is an Initial packet fully conforming
> with the specification, the server proceeds with the handshake", so Initial
> is first? Ok.
> What goes in the Initial packet?
> Section 17.2.2 references "destination connection id", "source connection
> id", "token", "packet number", and "payload". Token is covered right there,
> and it seems to be optional except for something called a Retry packet.
> There's also reference to NEW_TOKEN -- it's not clear if either of these
> tokens is required to be used from here. The payload is also in the same
> section with "The first packet sent by a client...", which is useful.
> Connection IDs are a bit more mysterious. Section 5.1.1 is titled "Issuing
> Connection IDs", but isn't very useful. Section 5.1 says "A zero-length
> connection ID can be used when a connection ID is not needed to route to
> the correct endpoint." so maybe they can both be empty? I'm skimming over
> all the frame talk since obviously I can't exchange frames yet. Reading
> through the rest of section 5, there's nothing in here. Turns out the
> answer is buried in the middle of section 7.2: "When an Initial packet is
> sent by a client that has not previously received an Initial or Retry
> packet from the server...". This took me literally fifteen minutes of
> searching to find. I was significantly impeded by the split between
> sections 5 and 7.
> Ok, what goes in Version? Can't be zero, that's version negotiation.
> Finally found it in the preamble of section 7. That's *certainly* not where
> I'd expected to find it at all.
> Eventually I realized that several of the remaining fields are actually
> defined in 17.2, and it is necessary to read QUIC-TLS to understand some
> special mangling that happens to all packets, even the first ones. (Why do
> Initial packets need header protection? Unclear.) Basically what I'm
> realizing is that these documents cannot be treated as two standalone
> layers of a protocol but are instead intertwined in a fairly complex way. :(
> In the end, it took me hours just to learn how the first packet works.
> I'll keep going, but I thought perhaps the feedback on my experience so far
> might help inform future changes to the document.
> (It would be nice to have more cross-references. An example packet flow
> that covers all of the packet details with references to the sections that
> constrain them would be *really* great. Figure 5 is good, but doesn't talk
> about things like connection IDs.)
> --
> JP Sugarbroad <>
> "Please let me know if there's any further trouble I can give you."
>     -- Unknown