Security Area Advisory Group (SAAG)
IETF 124 Montreal
0930-1100 Friday Session 1, 7 November 2025
Room: Viger
Minute-taker: Mike Ounsworth
PLANTS BoF is becoming a WG. ADs are looking for chairs. Charter is in
process.
SEAT working group met for the first time in Montreal.
Jim Fenton: Another working group to keep an eye on is DKIM2
W3C: They are updating XML Sig and writing a peper on Cryptography usage
in Web Standards. They have also presented to the IAB. The issue is
integrating the threat modeling process in a way that makes it easy for
authors/editors to understand the social impacts of a standard. (Deb
will forward to the saag list)
Longfellow: Eric Rescorla (EKR) suggests that before we decide where to
dispatch this, we should figure out which IETF protocol(s) want to
consume it. It is a building block. Rumors are that maybe SD-JWT?
Sean Turner (ST): About errata: He agreed that they would go through the
TLS errata and make the recommendations. It's a little bit discouraging
when someone thinks that they're gonna publish a simple update doc, and
they get saddled with a decade of errata to deal with at the same time,
but it is what it is, I guess.
Michael P: The Real World Cybersecurity side-meeting on Tuesday was
excellent. We had about 50 people. I will send around the recording.
Usama: We are proposing a new RG in the IRTF about confidential
computing which will handle some of the research questions that spill
over from adjacent IETF WGs such as RATS, SEAT, WIMSE etc.
Rüdiger Volk: He was impressed by the Sec Area statistics of 300
documents and 10,000 pages for an operator, that is frightening. Maybe
less is more?
Deb: There are building blocks that need to be in place before the
protocol to be deployed can be developed. An operator doesn't
necessarily need to read everything; for example an operator doesn't
need to read all the JOSE stuff in order to deploy SD-JWT.
Brian Contario (BC) presenting
The TOTP ecosystem typically has the user scan a QR code, which contains
not only the long-term secret of the TOTP, but also the username.
Problem.
Proposal is to replace the actual secret in the QR code with a
one-time-use (nonce-based) URL for retrieving the secret.
Zhang Jun: question about the usability of the scheme: how long would
the nonce be valid for?
BC: configurable. We're thinking of something in the range 30s - 5 mins.
Aaron Parecki: I know that TOTPs are not going away any time soon, but
it seems weird to improve TOTPs when Passkeys and other things exist.
This online suggestion does not handle well backing up your secrets to
offline or syncing them between devices.
EKR: What about a combined QR code that combined both the original TOTP
enrollment and this new enrollment mechanism so that the client could
switch hit. Then when the client enrolls with the new mechanism you
disable the original TOTP, so the QR code is no longer a risk. That way
the server can present just one code.
ST: You're defining your own URI scheme here which is gonna need some
coordination with various groups, and will probably hit resistance.
Bob Beck: You will need a very good security considerations section for
this because you're adding a channel where you can send a user a QR code
and then harvest a bunch of lovely metadata from their device.
Jonathan Hoyland: How would this work for TOTPs stored on a Yubikey
token which itself does not have an internet connection.