RFC 9369

QUIC Version 2

📅 published May 2023, from ietf

QUIC Version 2 🦋

okay bestie, let's talk about RFC 9369 💖 This doc defines QUIC version 2 (the document is by M. Duke at Google LLC, it's a Standards Track document, and it was published in May 2023). Heads up: this title block doesn't have an Obsoletes or Updates line, so this one doesn't replace or update any earlier RFC 🫶

  • Document: RFC 9369, QUIC Version 2
  • Author: M. Duke, Google LLC
  • Category: Standards Track
  • Date: May 2023
  • ISSN: 2070-1721
  • Obsoletes / Updates: none listed in the title block

Abstract

okay so this doc specifies QUIC version 2, and honestly it's giving QUIC version 1 with a few tiny glow-ups ✨ The whole point is to fight ossification (when stuff in the network gets so stuck on the current details that changing them becomes basically impossible) and to actually exercise the version negotiation framework 💅 It also doubles as a template for the minimum changes any future version of QUIC would need 🧚

Quick note: "version 2" is just an informal nickname. It means this is the second QUIC version to be published as a Standards Track document. The protocol here uses a version number that is not 2 on the wire, specifically to keep ossification risks low 🌸

Status of This Memo

This is an Internet Standards Track document. 🎀

This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

Info about the current status of this document, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9369 ✨

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License.

Table of Contents

1.  Introduction
2.  Conventions
3.  Differences with QUIC Version 1
  3.1.  Version Field
  3.2.  Long Header Packet Types
  3.3.  Cryptography Changes
    3.3.1.  Initial Salt
    3.3.2.  HMAC-based Key Derivation Function (HKDF) Labels
    3.3.3.  Retry Integrity Tag
4.  Version Negotiation Considerations
  4.1.  Compatible Negotiation Requirements
5.  TLS Resumption and NEW_TOKEN Tokens
6.  Ossification Considerations
7.  Applicability
8.  Security Considerations
9.  IANA Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Appendix A.  Sample Packet Protection
  A.1.  Keys
  A.2.  Client Initial
  A.3.  Server Initial
  A.4.  Retry
  A.5.  ChaCha20-Poly1305 Short Header Packet
Acknowledgments
Author's Address

1. Introduction ✨

okay so QUIC version 1 [QUIC] has a bunch of extension points 🧩 The big one is the version number, which sits in the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). Experimental versions are rare, and QUIC version 1 is the vast majority of QUIC traffic, so middleboxes could totally end up ossifying on the version bytes, which are usually 0x00000001 💀

Next, Initial packets in QUIC version 1 are encrypted with a version-specific salt, as described in Section 5.2 of [QUIC-TLS] 🔐 Protecting them this way lets observers read their contents, and those contents include the TLS Client Hello or Server Hello messages. So again, middleboxes could ossify on the version 1 key derivation and packet formats 🙈

Finally, [QUIC-VN] describes two ways endpoints can negotiate which QUIC version to pick 💜 The "incompatible" method can switch from any QUIC version to any other version with full generality, but it costs an extra round trip at the start of the connection. "Compatible" version negotiation gets rid of that round-trip penalty, but it puts some limits on how semantically different the two versions can be 🫶

QUIC version 2 is meant to fight ossification and exercise the version negotiation mechanisms 🦋 Its changes are an example of the minimum set of changes you'd need to specify a new QUIC version. Here's the twist though: the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1. Both of those are meant to combat ossification, and neither one is strictly required of a new QUIC version 🌸

Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks 🔥

2. Conventions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖

3. Differences with QUIC Version 1 🌈

Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY] 💅 The rest of this section lists those differences.

3.1. Version Field 🔢

The Version field of long headers is 0x6b3343cf. It was generated by taking the first four bytes of the sha256sum of "QUICv2 version number" 🧠

3.2. Long Header Packet Types 🦋

Every version 2 Long Header packet type is different 👑 Here are the Type field values:

  • Initial: 0b01
  • 0-RTT: 0b10
  • Handshake: 0b11
  • Retry: 0b00

3.3. Cryptography Changes 🔐

3.3.1. Initial Salt 🧂

The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

This is the first 20 bytes of the sha256sum of "QUICv2 salt" ✨

3.3.2. HMAC-based Key Derivation Function (HKDF) Labels 🏷️

The labels that [QUIC-TLS] uses to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change like this: "quic key" becomes "quicv2 key", "quic iv" becomes "quicv2 iv", "quic hp" becomes "quicv2 hp", and "quic ku" becomes "quicv2 ku". This is to meet the guidance for new versions in Section 9.6 of that document 🌸

3.3.3. Retry Integrity Tag 🎀

The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:

secret =
  0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
nonce = 0xd86969bc2d7c6d9990efb04a

The secret is the sha256sum of "QUICv2 retry secret". The key and nonce get derived from this secret using the labels "quicv2 key" and "quicv2 iv", respectively 🫶

4. Version Negotiation Considerations 🤝

QUIC version 2 is not meant to deprecate version 1 🙅‍♀️ Endpoints that support version 2 might keep supporting version 1 to maximize compatibility with other endpoints. HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. Since that mechanism doesn't currently tell QUIC versions apart, HTTP servers SHOULD support multiple versions. That lowers the chance of incompatibility and the cost of QUIC version negotiation or TCP fallback 💖 For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, because that was the original QUIC version used by HTTP/3. So some clients will only support that version 🌈

Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks 🔥

Also, version 2 meets the definition in [QUIC-VN] of a compatible version with version 1, and version 1 is compatible with version 2 too. So servers can use compatible negotiation to switch a connection between the two versions ✨ Endpoints that support both versions SHOULD support compatible version negotiation so they can avoid a round trip 🦋

4.1. Compatible Negotiation Requirements 📋

Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN] 📖

If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets that use other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token, so it can check that the client didn't switch versions. If the client did switch, the server can drop the packet, which enforces client compliance 🧚

QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1 does. After switching to a negotiated version following a Retry, the server MUST include the relevant transport parameters. Those validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC] 🔐

The server can't send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version 💅

The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, that means the negotiated version is equal to the original version 🫶

Before the server can process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version 🌸

Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version 🙈

Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints don't need to generate the keying material that would let them decrypt or authenticate such packets 🔥

The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version 🎀

5. TLS Resumption and NEW_TOKEN Tokens 🎟️

TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one 💜

Servers MUST validate the originating version of any session ticket or token, and not accept one issued from a different version. A rejected ticket means falling back to a full TLS handshake, without 0-RTT. A rejected token means the client address stays unverified, which limits how much data the server can send 😭

After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one ✨

(to be continued in part 2 🎀)

6. Ossification Considerations ✨

okay so QUIC version 2 has some protection against ossification 🛡️ but it's not perfect. Devices that assume every long header will say version 1, or that the version 1 Initial key derivation formula will never change, won't correctly process version 2 packets. 💀

Middleboxes like firewalls are the bigger issue, ngl. They tend to focus on the first packet in a connection, and that packet will often still be in the version 1 format for the reasons above. 🙈

Clients that want to fight middlebox ossification can start a connection with version 2, but only if they're reasonably certain the server supports it. They also have to be okay with a round-trip penalty if they guessed wrong. 🫶 A server that issues a session ticket for version 2 is basically saying it plans to keep supporting version 2 for as long as the ticket is valid, even though it can't guarantee that support. It's giving commitment 💍

7. Applicability 🦋

QUIC version 2 gives applications exactly the same capabilities as QUIC version 1, so no new vibes here. ✨ That means every Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoint that was specified for QUIC version 1 can also run over this version of QUIC. Both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2, periodt 💅

Unless stated otherwise, every QUIC extension that was defined to work with version 1 also works with version 2. 🌈

8. Security Considerations 🔐

Okay, this part is serious bestie 😭 QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

The mandatory version negotiation mechanism guards against downgrade attacks. Downgrades don't have security implications, though, because the version properties are identical. 👑

Support for QUIC version 2 can help an observer fingerprint both client and server devices. Not me noticing a privacy angle 👀 Keep that in mind when you deploy it. 🕵️‍♀️

9. IANA Considerations 📋

IANA has added the following entries to the "QUIC Versions" registry maintained at <https://www.iana.org/assignments/quic>. Here they are, straight from the registry:

Value:  0x6b3343cf
Status:  permanent
Specification:  RFC 9369
Change Controller:  IETF
Contact:  QUIC WG

Value:  0x709a50c4
Status:  provisional
Specification:  RFC 9369
Change Controller:  IETF
Contact:  QUIC WG
Notes:  QUIC v2 draft codepoint

10. References 📚

10.1. Normative References 🔒

10.2. Informative References 💜

Appendix A. Sample Packet Protection 🧪

This section is the test kit 🎀 It shows examples of packet protection so implementations can be verified step by step. Samples of Initial packets from both the client and server, plus a Retry packet, are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included too. Everything is in hexadecimal.

A.1. Keys 🔑

The labels generated during the execution of the HKDF-Expand-Label function (that is, HkdfLabel.label), and part of the value given to the HKDF-Expand function to produce its output, are:

client in: 00200f746c73313320636c69656e7420696e00

server in: 00200f746c7331332073657276657220696e00

quicv2 key: 001010746c73313320717569637632206b657900

quicv2 iv: 000c0f746c7331332071756963763220697600

quicv2 hp: 00100f746c7331332071756963763220687000

The initial secret is common to both sides:

initial_secret = HKDF-Extract(initial_salt, cid)
    = 2062e8b3cd8d52092614b8071d0aa1fb
      7c2e3ac193f78b280e72d8f5751f6aba

The secrets for protecting client packets are:

client_initial_secret
    = HKDF-Expand-Label(initial_secret, "client in", "", 32)
    = 14ec9d6eb9fd7af83bf5a668bc17a7e2
      83766aade7ecd0891f70f9ff7f4bf47b

key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16)
    = 8b1a0bc121284290a29e0971b5cd045d

iv  = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12)
    = 91f73e2351d8fa91660e909f

hp  = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16)
    = 45b95e15235d6f45a6b19cbcb0294ba9

The secrets for protecting server packets are:

server_initial_secret
    = HKDF-Expand-Label(initial_secret, "server in", "", 32)
    = 0263db1782731bf4588e7e4d93b74639
      07cb8cd8200b5da55a8bd488eafc37c1

key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16)
    = 82db637861d55e1d011f19ea71d5d2a7

iv  = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12)
    = dd13c276499c0249d3310652

hp  = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16)
    = edf6d05c83121201b436e16877593c3a

A.2. Client Initial 📦

The client sends an Initial packet. The unprotected payload of this packet contains the following CRYPTO frame, plus enough PADDING frames to make a 1162-byte payload:

060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff

The unprotected header indicates a length of 1182 bytes: the 4-byte packet number, 1162 bytes of frames, and the 16-byte authentication tag. The header includes the connection ID and a packet number of 2:

d36b3343cf088394c8f03e5157080000449e00000002

Protecting the payload produces an output that is sampled for header protection. Because the header uses a 4-byte packet number encoding, the first 16 bytes of the protected payload are sampled and then applied to the header as follows:

sample = ffe67b6abcdb4298b485dd04de806071

mask = AES-ECB(hp, sample)[0..4]
     = 94a0c95e80

header[0] ^= mask[0] & 0x0f
     = d7
header[18..21] ^= mask[1..4]
     = a0c95e82
header = d76b3343cf088394c8f03e5157080000449ea0c95e82

The resulting protected packet is:

d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485
dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04
9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d
250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a
12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500
cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68
18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33
12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3
d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd
6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520
bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045
636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f
ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12
16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5
4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4
fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b
8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7
14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9
9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91
abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd
80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db
848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18
d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15
c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc
7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61
f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710
10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b
3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e
06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce
8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1
34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1
e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd
5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3
8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89
d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53
6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19
9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b
a18b2faa745b6fe189cf772a9f84cbfc

A.3. Server Initial ✨

okay so the server replies with a payload that has an ACK frame, a CRYPTO frame, and zero PADDING frames 🫶 no padding bc the server isn't trying to pad anything here:

02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
020304

The header from the server gets a brand new connection ID, plus a 2-byte packet number encoding for packet number 1 🦋

d16b3343cf0008f067a5502a4262b50040750001

Now the header protection sample gets grabbed starting from the third protected byte. Main character moment 💅

sample = 6f05d8a4398c47089698baeea26b91eb
mask   = 4dd92e91ea
header = dc6b3343cf0008f067a5502a4262b5004075d92f

And the final protected packet looks like this 😭🌸

dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2
c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8
4bed8521e2e140

A.4. Retry 🎀

This one shows a Retry packet that could get sent back in response to the Initial packet from Appendix A.2. Lowkey tricky bit: the integrity check includes the client-chosen connection ID value of 0x8394c8f03e515708, but that value does NOT show up in the final Retry packet 🙈

cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
65dcc7b6

A.5. ChaCha20-Poly1305 Short Header Packet 🧚

This example walks through some of the steps you need to protect a packet with a short header. It uses AEAD_CHACHA20_POLY1305 💜

So TLS spits out an application write secret, and then the server uses HKDF-Expand-Label to make four values: a key, an Initialization Vector (IV), a header protection key, and the secret that gets used after keys are updated (that last one isn't used again in this example, so no stress 💀)

secret
    = 9ac312a7f877468ebe69422748ad00a1
      5443f18203a07d6060f688f30f21632b

key = HKDF-Expand-Label(secret, "quicv2 key", "", 32)
    = 3bfcddd72bcf02541d7fa0dd1f5f9eee
      a817e09a6963a0e6c7df0f9a1bab90f2

iv  = HKDF-Expand-Label(secret, "quicv2 iv", "", 12)
    = a6b5bc6ab7dafce30ffff5dd

hp  = HKDF-Expand-Label(secret, "quicv2 hp", "", 32)
    = d659760d2ba434a226fd37b35c69e2da
      8211d10c4f12538787d65645d5d1b8e2

ku  = HKDF-Expand-Label(secret, "quicv2 ku", "", 32)
    = c69374c49e3d2a9466fa689e49d476db
      5d0dfbc87d32ceeaa6343fd0ae4c7d88

Next up is protecting a minimal packet with an empty Destination Connection ID. This packet has a single PING frame (so the payload is literally just 0x01) and a packet number of 654360564. Here's the slay part: using a packet number of length 3 (so 49140 gets encoded) means you don't have to pad the payload. PADDING frames would only be needed if the packet number got encoded on fewer bytes 🔥

pn                 = 654360564 (decimal)
nonce              = a6b5bc6ab7dafce328ff4a29
unprotected header = 4200bff4
payload plaintext  = 01
payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba

The resulting ciphertext is the minimum size possible. One byte gets skipped to make the sample for header protection 🍓

sample = e7b6b932bc27d786f4bc2bb20f2162ba
mask   = 97580e32bf
header = 5558b1c6

And the protected packet is the smallest possible packet, at 21 bytes, which is so iconic ✨👑

packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba

Acknowledgments 🫶

The author wants to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their super helpful suggestions 💖

Author's Address 🌈

Martin Duke Google LLC Email: martin.h.duke@gmail.com

📦 where this page comes from