Monday, November 3, 2025 @ 22:00-00:00 UTC
Note Well
Scribe: Rich Salz, fixes from Dierdre
See the slides for more detail about each of these.
Well-Known ECH, Stephen Farrell, draft-ietf-tls-wkech
Moved the repo to tlswg org at GitHub. Resolved all open issues and
comments, spin a new version changing the GitHub repo, and then
WGLC.
Extended Key Update, Yaroslav Rosomakho,
draft-ietf-tls-extended-key-update
Changes: have a single EKU message, will create a new registry to
have subtypes. EKU has no failure response. Response may be delayed,
but you can't go back to normal key update. All error codes now
removed from the doc. First draft of security considerations: scope
of key compromise, DoS, ops guidance. Added state machine changes
(informative appendix). Seeking more implementation (have two) and
reviews.
Usama: how can you compromise application key but not long-term (E.g.,
certificate's) key? Why is only the latter in the trusted execution
environment? Yaroslav: I think it's a separate attack. Draft does not
talk about long-term credential. Paul: original pre-master secret is.
Seems to be a terminology mis-use, please open an issue so we can fix
it.
Viktor: did you think of a minimum number of bytes before doing EKU?
Yaroslav: we did look at it, there's no consistency. Viktor: if the
memory dump is during idle time and quick, could impersonate a party.
Dierdre: is that what post-compromise promises? Yaroslav: we'll update
security considerations.
Dennis: Seems a conflict with IANA registry you need to negotiate
ability to send additional messages. Yaroslav: no strong opinion,
registry doesn't cost much, experience shows not having one has caused
problems.
Yaroslav: have also noticed some TLS stacks are half-duplex, that's an
implementation issue we'll document.
Deirdre: FATT is reviewing.
Sean: propose doing WGLC and then wait for implementations.
ML-KEM Post-Quantum Key Agreement for TLS 1.3, Deirdre Connolly,
draft-ietf-tls-mlkem
Aligned with ECDHE-MLKEM doc on ML-KEM failures (just let TLS deal
with it).
Open issue to change Recommended D from N.
Implemented in many places.
Decide to close the PR and go to WGLC.
A Password Authenticated Key Exchange Extension for TLS 1.3, Laura
Bauman, draft-ietf-tls-pake
Review of open issues (most small, a couple-lines of change).
Discuss of message flow for PAKE that fits into the TLS message
flows (two message limit). Overview of 3 and 5 message PAKEs.
EKR: Do not support the bigger ones
DavidBen: Could also run the auth thing with channel binding, kind
of a split.
Sophie: If you do what DavidBen suggests, short auth strings would
also be nice. Not in the TLS layer.
ChrisW: The motivation was authenticate and just "do TLS" Maybe an
auth layer explicitly in the app or such.
Mohibul Mahmud: Question about deployment with PAKE and X509? Laura:
draft says to do both.
Jonathan: do the PAKE first and inject it into the TLS channel
binding?
Laura: need to talk with co-authors; it's a wierd layer between tls
and app.
#6 Discussion of one extension versus one per algorithm.
#21 What is client sends both PSK and PAKE? Server must choose.
#23 Add "tls" prefix to the content string
Open discussion.
Joe: Is there a concrete reason for a multi-round PAKE?
ChrisW: hybrid security (classic/PQ)
Dennis: good doc, useful. Suggest adding "if all you have is a
password, you might want to use this."
Jonathan:
Usama: Referring to an open issue re formal analysis - have it be
done. Have done some, need more review of the current version.
ChrisW: there is analysis under way. Happy to have more help.
Viktor: I think this can be more secure that the client is speaking
to the server that knows him. Don't discourage use.
Sophie: PAKEs only secure if you do rate-limiting of the number of
trials.
Deirdre: OQUAKE is pure PQ that fits in the existing 1RTT key
exchange, anyone want to do that?
Laura: yes we will.
Scott: both sides have to have the cleartext password which is an
issue.
DE Reports, Rich Salz
no questions, no discussion. See the slides.
WEDNESDAY
Administrivia (5min)
Note Well
Scribe: Mike Ounsworth, Chris I.
Working Group Drafts
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
(30min)
Eric Rescorla
draft-ietf-tls-rfc9147bis
PaulW [individual]: Replay detection sucks for performance; IPSEC is
discussing a way to turn it off.
MT: I'm concerned about not being able to send an ACK to a DTLS 1.2
client. But we're supposed to be able to throw away garbage, right? IE
if you're a DTLS 1.3 stack, just always send an ACK and hope that the
other end ignores stuff it doesn't support. We'd of course need to
convince ourselves that all existing 1.2 stacks ignore erroneous 1.2
data correctly.
ekr: not sure, didn't occur to me when thinking about this. this could
be handled as a unknown record type.
DavidBen: our stack might not handle unexpected ACKs. I'll have to go
check.
PaulW [individual]: IKEv2 has some similar mechanisms, for throwing
away garbage and retransmiting missing packets. Turn out some
connections cannot complete the handshake.
ekr: Not sure if the handshake would fail; describes how mechanism is
supposed to work.
deirdre [individual]: didn't SSH also have a bug similar to
unencrypted seq #s. should not do this.
No objections in the room to not adding nvidia's request of unecrypted
seq #s.
Turner to file issue for ekr to check errata on v1.3 / v1.2; ekr will
process.
Non-Working Group Drafts (5min)
PEM file format for ECH
Stephen Farrell
draft-farrell-tls-pemesni
Yaroslav: can this allow you to have multiple ECH Configs?
Stephen: this allows you to have multiple configs, but only one ECH
private key.
MT: if you want multiple keys, you can have multiple files. It is fairly
straightforward to combine ECH configs.
Usama: There was an extensive formal analysis. Was this change re-run
through formal analysis?
Deirdre: this is just a file format, does not break formal analysis of
the protocol/change TLS or ECH key schedule or cryptographic design.
Formal analysis not needed.
ekr: Are these separable? Can you have ECH config w/out the private key.
Stephen: yes, you can have 0 private keys.
Authenticated ECH Config Distribution and Rotation (25min)
Nick Sullivan
draft-sullivan-tls-signed-ech-updates
Stephen: He supports the effort, keeping working.
MT: I don't see the indirection via a public_name as something that
provides useful features, only more risk.
Nick: the server is selecting the public name, exclusively; you're
talking about the outter name in the SNI; which is different. (did I get
that right?) We're stuck with the public name based auth system for now
because that's how the system is built.
David Adrian: Supportive of getting rid of outer SNI; but are people
going to deploy this?
Nick: Yes, Cloudflare.
David: Google has issues with deploying this already, this update
doesn't solve Google's problems. Do we need this?
Nick: Not necessarily making deployment easier; but does make updates
and management easier.
Chris Patton: "I'm good". (the comment was about TOFU and how you trust
the ECHConfig on first use if the DNS is not DNSSEC-signed. Nick: but
that's how ECH works)
[I didn't capture it, because the comment worked out to be about
existing ECH, not the draft.]
Christian Huitema: struggling with how to do initial trust, especially
in a multi-CDN deployment, how to resolve the trust there?
Dennis Jackson: Multi-CDN deployments of ECH is non-trivial. Also, there
were comments about retry configs and recoverability with RPK. I just
wanted to say that this draft doesn't really change anything from how it
works today.
ekr: Have you talked to any CA's about issuing this type of cert?
Nick: no.
ekr: This is why you end up with IP binding and its an issue, especially
when you get to multi-CDN. Likely to prefer the RPK thing, but open to
being swayed for PKIX. The DNS overrides what you see from a server, and
that's the update.
Nick: that's right.
Alessandro Ghedini: if selecting 1-method, then RPK would be his choice.
BONUS PRESENTATION
Service Affinity Solution based on TLS
Aijun Wang
ekr: TLS is not the right layer for this; should be in the application
layer. If TLS was the right layer, this mechanism is not good.
Aijun: if we do it in the TLS layer, we can apply it to lots of
applications
ekr: right, but that's still broken. the applications get a weird state
of some packets delivered, some packets not delivered and the
application does know what has happened.
Aijun: QUIC has something similar.
ekr: but QUIC has a mechanism to reestablish the state of that
connection; TCP has to reastablish connection.
mt: superficially like QUIC's preferred handshake mechanism; but its not
complete. If that has http, you would do a redirect and change from an
anycast to direct IP address. The application above is seeing a TCP
connection break, and then packets start coming again.
aijun: Can you send to list. want the palo alto team to help.