Skip to content

Describe PQTLS interop issues #63

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tfpauly merged 2 commits into from
Mar 2, 2026
Merged

Describe PQTLS interop issues #63

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f166b2f
Describe PQTLS interop issues
tfpauly Mar 2, 2026
970e1ed
Update draft-iab-protocol-greasing.md
tfpauly Mar 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 18 additions & 1 deletion draft-iab-protocol-greasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}}).

Expand All @@ -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
Comment thread
tfpauly marked this conversation as resolved.
Outdated
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.
Copy link
Copy Markdown
Collaborator

@LPardue LPardue Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: For the archaologists, we did this during the QUIC standardization work by defining a"discard" extension (never formally registered) more info at https://github.com/quicwg/base-drafts/wiki/Quantum-Readiness-test. I don't think we need to explicitly mention it in the text but wanted to point it out before I forgot.


## Example: IPv6

The IPv6 protocol {{?IPV6=RFC8200}} defines the ability to use extension headers,
Expand Down