From f166b2f2885a3f1d498c3771f0ed45dfb1a1e2ff Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Sun, 1 Mar 2026 20:15:28 -0800 Subject: [PATCH 1/2] Describe PQTLS interop issues --- draft-iab-protocol-greasing.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index ab7f4d2..4c95b88 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -372,7 +372,7 @@ extension points positively. To some extent this can be thought of as protocol fuzzing. This might be difficult to exercise because varying the protocol elements might change the outcome of interactions, leading to real errors. However, some protocols allow elements to be safely changed, as shown in the -following examples. The principles in these two examples are not limited to +following examples. The principles in these examples are not limited to the protocols mentioned, but also arise in many other protocols as well (e.g., the Session Initiation Protocol (SIP) {{?SIP=RFC3261}}). @@ -397,6 +397,23 @@ aspects of a transmission, which may not be acceptable for a given use case. As such, positive testing might be most appropriate to use in a subset of connections, or phases within a connection. +## Example: Post-quantum key exchange in TLS + +Post-quantum key exchange in TLS (such as defined in +{{?PQTLS=I-D.ietf-tls-ecdhe-mlkem}}) expands the key sizes sent in Client Hello +messages in TLS 1.3 {{?TLS=RFC8446}}. Before using these algorithms, +Client Hello messages would generally fit within a single packet (either in +TCP or QUIC). However, with these larger keys, Client Hello messages need to be +split across two separate packets. Initial deployments of these keys uncovered +many buggy server and middlebox implementations that did not correctly handle +Client Hello messages being split across multiple packets. + +This is a case in which adding variability to how TLS Client Hello messages were +sent could have helped avoid ossification and buggy implementations. Variations +could include intentionally splitting the messages across packets without increasing +message size, and also adding other values to messages to force them to exceed +the length that can fit within a single packet. + ## Example: IPv6 The IPv6 protocol {{?IPV6=RFC8200}} defines the ability to use extension headers, From 970e1ed5bad2637d5e2dfed6a75c5f3d582658ae Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Mon, 2 Mar 2026 06:30:24 -0800 Subject: [PATCH 2/2] Update draft-iab-protocol-greasing.md Co-authored-by: Lucas Pardue --- draft-iab-protocol-greasing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index 4c95b88..be3fc96 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -404,7 +404,7 @@ Post-quantum key exchange in TLS (such as defined in messages in TLS 1.3 {{?TLS=RFC8446}}. Before using these algorithms, Client Hello messages would generally fit within a single packet (either in TCP or QUIC). However, with these larger keys, Client Hello messages need to be -split across two separate packets. Initial deployments of these keys uncovered +split across two (or more) separate packets. Initial deployments of these keys uncovered many buggy server and middlebox implementations that did not correctly handle Client Hello messages being split across multiple packets.