Thursday, July 23, 2026 @ 07:00-09:00 UTC
Notes: Rich Salz, Muhammad Usama Sardar (assist)
Chairs made revisions, no bashing from the floor.
For more details, see the Chair slides. For details on draft slides.
Complaints about ML-KEM and ML-DSA drafts were denied by the chairs (and
then escalated)
Seven RFCs published; two drafts.
extended-key-update going to wait for FATT analysis before WGLC.
pake draft will be sent to FATT.
Usama: PAKE authors seemed ready for WGLC in the last meeting. They have
even made their formal analysis public and shared on the list.
What is blocking sending the initial FATT review request?
Many need implementation experience: super-jumbo-record-limit,
key-share-prediction, trust-anchor-ids, tlsflags, wkech.
Hannes: working on implementation of jumbo-record-limit, as is John
Mattsonn.
Hoyland: I wrote draft-jhoyla-tls-extended-key-schedule on how
to do key update to make it analysis-friendly; worth publicizing to
authors?
EKR suggests PQ-continuity draft also go to FATT since it is related
to extended-key-update.
ecdhe-mlkem consensus is now RECOMMENDED=Y and standards track.
mlkem draft is informational and RECOMMENDED=N (and being appealed).
List behavior has been bad. Chairs will be quicker to act and using new
tools (e.g., squelching off-topic threads).
Poll Do you want the list to get more functional? y/n/no-opinion 81/0/3
Support for this from EKR, Paul Wouters
Usama: can we stop having appeals traffic on the list? Sean: yes.
Usama: It would be helpful if you could use easier vocabulary or define
some words, like "dolling out" for the non-native speakers. Sean: yes
Tanja: even when you ask "no discussions" there are discussions. Sean:
this will be a learning experience, we will make mistakes.
Poll: Should chairs be moderating more actively? y/n/no-opinion 65/2/7
Note: Some "draconian" language was used in the actual poll but chairs
clarified that the intent was as mentioned above.
Christian: Mixed feelings, don't want to suppress dissent. Sean: agree
with the point.
Daniel: same as Christian. I did not answer because it took me time to
find the the poll.
Lars: I think in exceptional circumstances (like current) where the list
is "being destroyed" for the last couple of weeks or months, you need
more tools. Sean: hearing from folks who don't want to come, that's bad.
Slides about what is off-topic; adding "excessive process deliberations"
to the monthly reminder.
FATT has been a bumpy road (e.g., not consistently applied), still think
FATT review is valuable, Chairs smoothing out some of the bumps; see
https://github.com/tlswg/tls-fatt and PR 24 there.
Viktor: Proposes design for implementation and usability first and then
analysis comes second. (PSK as an example)
Usama: There were clearly transparency concerns which we all agree and
which have been addressed. I believe the opinions of those who have
previously done formal analysis should be taken into consideration when
making a decision. If authors or someone has already started formal
analysis, they have somehow made a judgement that formal analysis is
useful and required. If chairs come up with a conclusion that formal
analysis was not required, they will be shocked by this decision. It's
better to present the rationale of such a decision to the WG.
Thom: (speaking as individual) Procedural discussions are distraction.
It is upto the chairs to invoke the FATT process.
Felix: View FATT as a tool for those who do not know much about formal
analysis. Does it bring value? Formal analysis will be valued even if
not required.
Poll: Are FATT procedural discussions a distraction? y/n/no-opinion
80/0/3 (AI Notes said 35/0/8)
Poll: Should chairs be the ones that determine whether a draft goes for
the initial sniff test? 42/1/4
Usama: Question2 is not clear to me. Does it mean chairs only without
informing anyone and without sharing rationale?
Sean: chairs only but inform the WG with rationale
Poll: Do you think authors and those performing the formal analysis
collaborate? 49/2/8 (AI:42/3/8)
EKR: Formal analysis shouldn't need a special rule.
MikeO: voted no; authors is a well-defined set but those performing
formal analysis is not. Sean: Chairs aren't operating in a vacuum
Chris: agree with EKR. This does not need a process.
Thom: Reminder FATT doesn't do formal analysis, evaluate if the claims
in the doc are reasonable and supported by the doc and then the WG
decides what to do.
Close to having most issues raised addressed.
PR to make replay protection mandatory.
DavidBen: Support.
MT: QUIC replay has never shown in any perf analysis. Support.
Hannes: IPsec perf with sequence numbers in datacenter shows a cost, but
not yet done for general use. The case is weaker we think. Support.
Sean: anyone opposed willling to go to mic? (no)
Epoch closure; needs more review.
Acks during epoch transition. Please review.
Eric Rescorla requested further offline review from David Benjamin and
Martin Thomson to finalize this logic.
Once these are done, planning on asking WGLC. If you have open issues,
open them now.
Hannes: Have an interop matrix, please add to it if you know of other
implementations.
Hannes: have a student doing DTLS 1.3 analysis, hope to be done by WGLC.
Sean: Send to Chris wood mailing list.
(draft-sullivan-tls-signed-ech-updates)
EKR/Dennis: there is one issue we need to address if we adopt this.
There are two different types of replay: one is relatively modest and
the other one is a serious situation. Eric Rescorla raised concern about
replay attacks on signed "disablement" ECH configs, noting that an
attacker could replay a disablement config to turn off ECH for the
client. Dennis Jackson noted this is an active design trade-off:
preventing the replay would require keeping the signing key online in
the TLS server, which defeats the offline-signing benefit.
Alicia: What about clock drift? Should be addressed/mentioned in draft.
Alessandro: will look at it.
Poll: have you read the draft? 11/28/4
Poll: adopt? 12/9/19
draft-rosomakho-tls-wimse-cert-hint
Viktor: Overlap with a doc in DANCE which is similar, maybe talk to
Shumon to see if it makes sense.
Yaroslav: interesting, but DANCE is unknown in WIMSE.
EKR: Make the draft more general, not just WIMSE
Daniel: I like the draft; support adoption.
Kyle: Wish we didn't need this, but we do. +1 EKR.
Shumon: Will read draft before I opine about
Poll: read the draft? 8/19/0
Chairs: Will consider adoption at next IETF.
draft-rosomakho-tls-supplemental-auth
Usama: Why not RFC9261/9266?
Yaroslov: don't change handshake or application code.
Usama: RFC9261/9266 doesn't change handshake and a shim layer could
avoid changes in application code.
Jonathan: could you have a pause extension that says "wait until you get
more certificates"?
Yarsolov: are you saying if we did that don't need formal analysis?
Jonathan: yes
Andrei: this is part of the handshake
Yaroslov: Yes, but not changing key schedule.
Kyle: do yo uwant to use same connection with diferent identities?
Yaroslov: no, carry multiple identies that identify one entity.
Alicja: server side of this scares me. I understand the need. Policy
decision, server can just reject app data until
Stefan: impact and on proxies?
Yaroslov: yes, needs to bne supported by lots of infrastructure
Viktor: RPK?
Yaroslov: only certificates supported.
Guilin: I like the multiple use-cases; I have another. We have a similar
draft multi-authentication in IPsec.
Dennis: This is a bad direction to go for in PQ (e.g., PQ PAKE
multi-handshake messages)
Hannes: Understand use-cases, not sure solution is right. Doing exporter
at the application layer was the wrong layer.
Sean: Talk to those who spoke against.
Richard Barnes: does this need an online CRQC?
Yaron: No, prepare the DSA cert off-line and then attack later.
Poll: who has read the draft? 14/12/0
EKR: After 125 we said dicuss deployment on the list? Has that changed?
Yaron: only know of our POC implementation.
DavidBen: Some flavor of this makes some sense but TLS is probably too
low-level (e.g., HTTP has cross-site cookies) and that it's an
application-level.
Dennis: agree this is the wrong level, prefer HTTP layer solution.
Usama: I don't see why PQ is the only motivation and not other
transitions?
Yaron: We had HSTS for plaintext->TLS, this is different.
Guilin:
Note Well
Scribes: Mike Ounsworth, Muhammad Usama Sardar, Morgane Guerreau
Chris Wood
draft-ietf-tls-pake
Nick (in chat):
https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/
if there's interest, we can revive it, but it diverges a lot from the
design of this draft, and would probably need revisiting.
Ekr: Is Finished message providing key confirmation?
If you have record layer broken, the key confirmation still remains?
Scott: Could be put in independent draft.
Viktor: Resumption tickets (PSK) and post-handshake authentication; DH
key agreement;
We don't always negotiate the groups.
Usama: Can you expand on the formal analysis work left to be done that
you need help with?
Chris pointed to the list on Slide 8.
Show of Hands: (Questions presented prior to presentaitons, show of
hands poll done after presentations)
Jonathan Hoyland (in chat):
I just don't know how to evaluate what it is I am supposed to be
voting on? What's the precise property we're looking for? Is it both
hedging against a failure in ML-DSA or ECDSA, or just a hedge one
way or the other?
Usama: Slides were uploaded quite late.
Chris Wood (speaking for No): The WG doesn't need to spend time on this:
send the codepoints to IANA and move on.
Yes: 51 / No: 11 / No opinion: 14
Yes: 8 / No: 51 / No opinion: 12
Yes: 53 / No: 8 / No opinion: 17
4b. Can we allocate code points and not adopt the draft?
Yes: 31 / No: 23 / No opinion: 8
Did not happen
Did not happen
Did not happen
Hannes Tschofenig & Rifaat Shekh-Yusef
draft-yusef-tls-pqt-dual-certs
David: This is unrelated to SAAG problem.
Hannes: SAAG was focused on web. We could benefit from a document that
describes different solutions for different problem domains.
Jonathan: Output of the first signature is not an input to the second
signature. Why or why not?
Rifaat: We did consider that.
Tiru: Several approaches. Referred to analysis done in ??PQUIP?? about
combining signatures, and this is ok.
Andrei Popov: in what sense does it provide backward compatibility when
it requires a server update?
Rifaat: you gradually move out until tou get wherever you want to end up
Usama: Some PQUIP analysis was mentioned but what is the relationship
between the two keys? How is it ensured that the two keys are coming
from the same server and not from two servers? What is the rationale for
not taking the output of first signature as an input to the second
signature?
Hannes: the certificate message now includes the two chains
Eric: those internal algorithm can only be used to sign CertifcateVerify
Viktor: this looks like hybrid with CAs that don't do hybrid. The main
thing is that we get the CA out of the loop and it's easier to provision
the two parts separately
Hannes: that's a separate document
Tiru: Enterprise use case here (both controlled by the same entity)
compared to web use case of David.
Bob Beck: If the goal here is for an upgraded server to be able to serve
both upgraded and non-upgraded servers then you need certificate
negotiation.
Authors: This draft includes certificate negotiation (downgrade to
single cert)
David Benjamin (in chat):
Practically every TLS stack in the world exposes "get me the peer
certificate" as API somewhere. Implicit in that API's existence is the
assumption that there is just one peer certificate.
John Preuß Mattsson (in chat):
It seems like the Web will use standalone ML-DSA-44, which I think is
a good choice. If we need something more conservative, I think the
following are the 2 best choices:ML-DSA-65 and ML-DSA-87
SLH-DSA
I think non-composite signatures that avoid compinatorial explosion
and allow PQ/PQ hybrids have value, but I am not conviced by the
current proposal.For composites I think we should wait for CFRG. 40 people voted for
CFRG working on composites.
Sophie Schmieg (in chat):
To expand: hybrids are not a method for migrating to PQC, they are a
security mechanism to be as secure as the more secure one
Mixing those two goals is very dangerous
Jonathan Hoyland (in chat):
if you sign the inner one with the outer, and the outer has a
commitment to the master key then you should naturally get the
security of both, i.e. stronger than Sophie's definition.
Tiru Reddy
draft-reddy-tls-composite-mldsa-10
\:::info
Note: This section was restored using the YouTube transcript
(https://www.youtube.com/watch?v=Qp1s1UMmhTI) starting at the 40:49
timestamp. (AI assisted)
\:::
Tiru:
Composite is another scheme that has been worked on for a few years in
the LAMPS working group and is already in the RFC editor queue. It
treats PQC and traditional signatures and public keys as an atomic
operation, meaning verification succeeds only if both verify. This
provides defense in depth and resilience for regulatory reasons.The approach requires minimalistic changes to TLS 1.3, using existing
extensions with no new handshake messages or delimiters. It is treated
as an opaque signature algorithm where hashing is internal, so TLS
does not have to select a hash algorithm. The selected algorithms are
an intersection of LAMPS composite algorithms and TLS 1.3 recommended
traditional algorithms (excluding Brainpool).Composite signatures are also being used by IPSec, JOSE, and SSH. The
scheme provides UF-CMA (forging requires breaking both components).
The lack of SUF-CMA is not an issue for TLS since every handshake
transcript is unique. Advantages include a single certificate, one
chain on the wire, one chain to validate, and a single CA. Ultimately,
both approaches have pros and cons depending on the deployment.
Sean: All right. So, clarifying questions. We had another 21 minutes
scheduled for this, so I want to reserve at least seven minutes of that
for the show of hands. But if this is a clarifying question, please get
to the mic. Nicola.
...
Nicola: deployed mTLS in constrained devices with composite ML-DSA, very
positive feedback because it's opaque; simplified
Ekr: whether do it at all?
Eric Rescorla, Rich Salz, and Dennis Jackson questioned the overall
utility of hybrid signatures, suggesting that simple algorithm
transitions may be preferable. However, they noted that if the working
group chooses to support a hybrid signature mechanism for "hedging," the
composite approach has a significantly lower protocol and API complexity
cost.
If we go for it, what properties are we looking for?
Dennis: 2 use cases: 1. transition and backward compatibility; 2.
hedging
composites approach could be valuable for hedging, but personally I'm
not excited about it.
Sean: One over the other or do it at all?
Chris W: There are use cases where people want this as a hedging
improvement over existing classical deployments Composites is a vastly
simpler approach for those use cases It gets us code points to you. For
example, hybrid signatures with raw public keys And there are real-world
deployments that also want hybrid So, as to Ekr's question as to whether
or not we should do this. Not really sure what that means.
John Gray (Entrust): We definitely need this and I guess the reason for
having a draft that I mean, we at least need code points.
Andrei (Microsoft): We have use cases and we would like to use it.
Preferred approach is composite. At least code points would be great.
Rich: More concrete examples of what needs this addresses
Sean: Some jurisdictions require this.
Jonathan: What property are we going here? Both be broken or only the
outer one needs to be broken?
Usama (in chat): Property should be both broken
David B: Assume this is hedging (vs. transition). Cost vs. value: if we
have to choose one, composites is the way to go. Fairly niche thing.
Hannes: Use case: everything outside of web is ignored.
Andrei: Changing key requires change in configuration.
Chris W: niche but real.
Ekr: Composites are vastly easier to do, in fact they're like already
done.
Nick Sullivan
draft-sullivan-tls-xof-ciphers
Usama: Formal (symbolic) analysis takes ideal one-way functions. So it
may not be that helpful. I think what would help here is probably
computational (cryptographic) analysis.
Jonathan Hoyland (in chat):
For the Tamarin analysis I'd have to check, but I think the proofs
would pretty much go through unchanged?
Quynh: NIST will review it. If it does not
John: supported the work, noting that a SHA-3-based family option is
highly desirable given the PQC migration.
Ekr: argued that instead of negotiating the key schedule profile via a
new TLS extension, it would be architecturally cleaner to define new
cipher suites that natively map to SHA-3/Keccak transcript hashes and
key schedules.
Jonas Muecke
Towards a Complete View of Encrypted Client Hello Deployments
Kyle: We have one of our major apps that is actively using UC8s widely.
Gianpaolo: just one client facing server