[{"author": "Paul Wouters", "text": "

to clarify: It will go back on to an IESG telechat, just not doing another IETF Last Call

", "time": "2025-07-21T15:06:36Z"}, {"author": "Carsten Bormann", "text": "

Thanks!

", "time": "2025-07-21T15:07:02Z"}, {"author": "Mike Ounsworth", "text": "

Out of personal curiosity, what are the uses for SLH-DSA in COSE?

", "time": "2025-07-21T15:10:29Z"}, {"author": "John Bradley", "text": "

The question is unclear. Yes eventually but not now

", "time": "2025-07-21T15:13:46Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Firmware update was mentioned as a COSE use case for SLH-DSA. NIST is expected to release more optimized parameters in the future.

", "time": "2025-07-21T15:14:47Z"}, {"author": "Sophie Schmieg", "text": "

Afaik some firmware signing use cases use cose

", "time": "2025-07-21T15:15:14Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Everybody wants PQC signatures, standalone ML-DSA and FN-DSA is forbidden by ANSSI/BSI/EUCC, XMSS/LMS is stateful and NIST forbids private key backup, and FN-DSA (Floatingpoint Nightmare-DSA) has implementation issues... so SLH-DSA might be the only viable choice sometimes....

", "time": "2025-07-21T15:17:25Z"}, {"author": "Mike Ounsworth", "text": "

Yeah, firmware makes sense. That's a case where you have big central servers sending stuff to small light clients. And you want long-term trust. Seems like a 100% reasonable use for HBS.

", "time": "2025-07-21T15:19:05Z"}, {"author": "Mike Ounsworth", "text": "

@Minute-takers: I would change my vote for SLH-DSA from \"No Opinion\" to \"Yes\" :P

", "time": "2025-07-21T15:20:19Z"}, {"author": "Russ Housley", "text": "

In LAMPS, we call that attack the \"Falko Attack\"

", "time": "2025-07-21T15:20:49Z"}, {"author": "Sophie Schmieg", "text": "

John Preu\u00df Mattsson said:

\n
\n

FN-DSA (Floatingpoint Nightmare-DSA)

\n
\n

I'll have to steal that, I'm sorry

", "time": "2025-07-21T15:24:02Z"}, {"author": "Marco Tiloca", "text": "

Mike Ounsworth said:

\n
\n

@Minute-takers: I would change my vote for SLH-DSA from \"No Opinion\" to \"Yes\" :P

\n
\n

Done :-)

", "time": "2025-07-21T15:28:38Z"}, {"author": "Sophie Schmieg", "text": "

You want to perturb the key gen, ideally

", "time": "2025-07-21T15:34:20Z"}, {"author": "Renzo Navas", "text": "

Does anyone know if \"Zalcon\" (an alternative FPA-free NTRU sampler for Falcon) is being considered in the current NIST review of FN-DSA? ( https://csrc.nist.rip/Presentations/2021/zalcon-an-alternative-fpa-free-ntru-sampler-for-fa , there is a paper too) .

", "time": "2025-07-21T15:44:35Z"}, {"author": "Russ Housley", "text": "

Is this what I am hearing: \"There was no one in the room that advocated for COSE_Mac use case, and the authors want to dropp it from the document.\"

", "time": "2025-07-21T15:52:06Z"}, {"author": "Deirdre Connolly", "text": "

John Preu\u00df Mattsson said:

\n
\n

Everybody wants PQC signatures, standalone ML-DSA and FN-DSA is forbidden by ANSSI/BSI/EUCC, XMSS/LMS is stateful and NIST forbids private key backup, and FN-DSA (Floatingpoint Nightmare-DSA) has implementation issues... so SLH-DSA might be the only viable choice sometimes....

\n
\n

'forbidden'? Aren't BSI recommendations just that, recommendations?

", "time": "2025-07-21T15:56:33Z"}, {"author": "Deirdre Connolly", "text": "

Renzo Navas said:

\n
\n

Does anyone know if \"Zalcon\" (an alternative FPA-free NTRU sampler for Falcon) is being considered in the current NIST review of FN-DSA? ( https://csrc.nist.rip/Presentations/2021/zalcon-an-alternative-fpa-free-ntru-sampler-for-fa , there is a paper too) .

\n
\n

I have not heard any concrete on this, we'll know for sure if we ever get an FN-DSA IPD

", "time": "2025-07-21T15:57:30Z"}, {"author": "Renzo Navas", "text": "

Ok, thanks. IMHO will be good news to have a FPA-free Falcon (the proposal is from a subset of the original Falcon designers), but we have to wait and see indeed

", "time": "2025-07-21T16:01:30Z"}, {"author": "Ira McDonald", "text": "

SP-800 232 is Initial Public Draft - not a 2nd Public Draft yet

", "time": "2025-07-21T16:15:26Z"}, {"author": "Christian Ams\u00fcss", "text": "

Looking forward to using this. As John said: can work on it already.

", "time": "2025-07-21T16:16:15Z"}, {"author": "Christian Ams\u00fcss", "text": "

Ideally, I'd like this to go out of this WG once it is confirmed that the test vectors from the released NIST don't differ from the version that the draft was built on.

", "time": "2025-07-21T16:16:35Z"}, {"author": "Robert Moskowitz", "text": "

My connection broke. I am interested in seeing this draft advanced in the wg.

", "time": "2025-07-21T16:18:49Z"}, {"author": "Robert Moskowitz", "text": "

I am willing to read the draft and post feedbacks.

", "time": "2025-07-21T16:19:30Z"}, {"author": "Christian Ams\u00fcss", "text": "
\n

can't be as easily misinterpreted as \u2026

\n
\n

don't make it a challenge ;-)

", "time": "2025-07-21T16:22:01Z"}, {"author": "Deirdre Connolly", "text": "

What Sophie said

", "time": "2025-07-21T16:25:53Z"}, {"author": "Deirdre Connolly", "text": "

external Mu does exist and is real

", "time": "2025-07-21T16:26:08Z"}, {"author": "Deirdre Connolly", "text": "

by real I mean FIPS approved

", "time": "2025-07-21T16:26:28Z"}, {"author": "Sophie Schmieg", "text": "

Basically, why have two algorithms, when you can have one algorithm instead?

", "time": "2025-07-21T16:28:00Z"}, {"author": "Mike Ounsworth", "text": "

I am quite happy for my name to be invoked in reference to this draft :)

", "time": "2025-07-21T16:29:30Z"}, {"author": "Sophie Schmieg", "text": "

There is a few footnotes I have on this, which I have in a paper draft that I really need to polish up and put on eprint

", "time": "2025-07-21T16:30:48Z"}, {"author": "Deirdre Connolly", "text": "

Can we upgrade to modern hash functions like SHA3 or SHAKE?

", "time": "2025-07-21T16:31:02Z"}, {"author": "Deirdre Connolly", "text": "

or TurboSHAKE or whatnot

", "time": "2025-07-21T16:31:26Z"}, {"author": "Sophie Schmieg", "text": "

There is in particular an issue with hash-and-sign schemes, which decompose this way, but can have key leakage issues

", "time": "2025-07-21T16:31:42Z"}, {"author": "Jonathan Hammell", "text": "

I think \"split signing\" still suggests MPC. Perhaps \"signing with external hash\"?

", "time": "2025-07-21T16:31:59Z"}, {"author": "Sophie Schmieg", "text": "

RSA in particular has a forgery issue

", "time": "2025-07-21T16:32:22Z"}, {"author": "Mike Ounsworth", "text": "

Deirdre Connolly said:

\n
\n

Can we upgrade to modern hash functions like SHA3 or SHAKE?

\n
\n

I'm currently having a similar discussion with Richard Barnes on exactly the same topic w.r.t. cfrg-hybrid-kem. See Deb's monolog at PQUIP Prague about the fact that SHA2 is better adopted than SHA3, so anywhere that you split ML-DSA from the pre-hasher into different layers, don't assume SHA3 is present.

", "time": "2025-07-21T16:32:25Z"}, {"author": "Deirdre Connolly", "text": "

Mike Ounsworth said:

\n
\n

Deirdre Connolly said:

\n
\n

Can we upgrade to modern hash functions like SHA3 or SHAKE?

\n
\n

I'm currently having a similar discussion with Richard Barnes on exactly the same topic w.r.t. cfrg-hybrid-kem. See Deb's monolog at PQUIP Prague about the fact that SHA2 is better adopted than SHA3, so anywhere that you split ML-DSA from the pre-hasher into different layers, don't assume SHA3 is present.

\n
\n

This is less of an issue for just needing collision resistance or whatever for message pre-hashing for signing, we need functions that are secure ROs for the hybrid-KEM functions

", "time": "2025-07-21T16:33:15Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Deirdre Connolly said:

\n
\n

Can we upgrade to modern hash functions like SHA3 or SHAKE?

\n
\n

I'm currently having a similar discussion with Richard Barnes on exactly the same topic w.r.t. cfrg-hybrid-kem. See Deb's monolog at PQUIP Prague about the fact that SHA2 is better adopted than SHA3, so anywhere that you split ML-DSA from the pre-hasher into different layers, don't assume SHA3 is present.

\n
\n

This is less of an issue for just needing collision resistance or whatever for message pre-hashing for signing, we need functions that are secure ROs for the hybrid-KEM functions

\n
\n

SHA-256 can _if you hold it correctly_ may be used this way but SHA3 is indifferentiable from a random oracle no matter how you hold it

", "time": "2025-07-21T16:34:00Z"}, {"author": "Sophie Schmieg", "text": "

For ML-DSA, I have a security proof

", "time": "2025-07-21T16:34:28Z"}, {"author": "Mike Ounsworth", "text": "

Right, we can talk about Hybrid KEMs in a different forum.
\nThe point is that here you'll get much better adoption with a MTI SHA2 pre-hash.

", "time": "2025-07-21T16:34:28Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Deirdre Connolly said:

\n
\n

Can we upgrade to modern hash functions like SHA3 or SHAKE?

\n
\n

I'm currently having a similar discussion with Richard Barnes on exactly the same topic w.r.t. cfrg-hybrid-kem. See Deb's monolog at PQUIP Prague about the fact that SHA2 is better adopted than SHA3, so anywhere that you split ML-DSA from the pre-hasher into different layers, don't assume SHA3 is present.

\n
\n

This is less of an issue for just needing collision resistance or whatever for message pre-hashing for signing, we need functions that are secure ROs for the hybrid-KEM functions

\n
\n

SHA-256 can _if you hold it correctly_ may be used this way but SHA3 is indifferentiable from a random oracle no matter how you hold it

\n
\n

Mostly I'm just noting that it's 2025, if we're writing new things down, why not modern things instead of being chained backwards forever

", "time": "2025-07-21T16:35:08Z"}, {"author": "Sophie Schmieg", "text": "

For external mu

", "time": "2025-07-21T16:35:35Z"}, {"author": "Sophie Schmieg", "text": "

And in particular, a way of reducing the security of external mu ML-DSA to the same underlying zero knowledge protocol ML-DSA itself also reduces to, not reducing them to each other

", "time": "2025-07-21T16:36:24Z"}, {"author": "Mike Ounsworth", "text": "
\n

Mostly I'm just noting that it's 2025, if we're writing new things down, why not modern things instead of being chained backwards forever

\n
\n

Honestly, Deb explains it better:
\nhttps://www.youtube.com/watch?v=W46QrMvlLZU&t=5652s

\n
", "time": "2025-07-21T16:36:58Z"}, {"author": "Christian Ams\u00fcss", "text": "

Reiterating from last time: If we introduce a channel to convey extra parameters, I don't quite see why we create new registrations of numbers -- we could just use the same numbes, and the presence of an (even empty) \"things you need to know when doing a split hash\" clues things off.

", "time": "2025-07-21T16:37:49Z"}, {"author": "Sophie Schmieg", "text": "

For Falcon, when I say I'm pretty sure there is a key recovery attack, I mean, I think there is, but my attempt at actually reducing the lattice failed

", "time": "2025-07-21T16:38:40Z"}, {"author": "Christian Ams\u00fcss", "text": "

Willing to review, pester me if I don't.

", "time": "2025-07-21T16:38:53Z"}, {"author": "Mike Ounsworth", "text": "

Hand up for helping Mike Jones with this draft.

", "time": "2025-07-21T16:39:24Z"}, {"author": "Mike Ounsworth", "text": "

You should not be able to tell the difference between \"I streamed the whole cat video to my HSM\" and \"CAPI pre-hashed it first\". This is \"implementation detail\" of the internals of the signer.

", "time": "2025-07-21T16:42:27Z"}, {"author": "Daniel Gillmor", "text": "

why do i care as a verifier how many steps were used?

", "time": "2025-07-21T16:42:46Z"}, {"author": "Jonathan Hammell", "text": "

The Digester and the channel between the Digester and Signer must be trusted.

", "time": "2025-07-21T16:45:18Z"}, {"author": "Sophie Schmieg", "text": "

Yes, that's why forgery attacks do not matter, but key recovery attacks do

", "time": "2025-07-21T16:45:56Z"}, {"author": "Amaury Chamayou", "text": "

Is there a construction that would enable a verifier to check in how many steps the computation was done? It doesn't seem like there is?

", "time": "2025-07-21T16:46:06Z"}, {"author": "Sophie Schmieg", "text": "

That's why I dislike hash ML-DSA

", "time": "2025-07-21T16:46:26Z"}, {"author": "Sophie Schmieg", "text": "

The fact that there are multiple steps and the verifier can tell

", "time": "2025-07-21T16:46:45Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hammell said:

\n
\n

The Digester and the channel between the Digester and Signer must be trusted.

\n
\n

Not to be cheeky, why?
\nThis is Sophie's (forthcoming?) paper about the security of External Mu mode of ML-DSA. At worst, the signer can produce a busted signature, but not an insecure signature. So concretely, why does this matter?

", "time": "2025-07-21T16:46:49Z"}, {"author": "Christian Ams\u00fcss", "text": "

Well, the verifier can ask some form of attestation on who holds the key, but that'll be asking way more things than just \"is there or is there not an internal split of hashing and signing\"

", "time": "2025-07-21T16:46:58Z"}, {"author": "Deirdre Connolly", "text": "

The 'indistinguishability' of how the signature is produced is a nice privacy property

", "time": "2025-07-21T16:47:12Z"}, {"author": "Christian Ams\u00fcss", "text": "

(@Amaury)

", "time": "2025-07-21T16:47:24Z"}, {"author": "Jonathan Hammell", "text": "

If you are doing Sign then Encrypt, if the channel does not provide confidentiality protection, you leak the plaintext.

", "time": "2025-07-21T16:48:19Z"}, {"author": "Sophie Schmieg", "text": "

I don't think attestation is a useful property here, that's not what prehashing is trying to solve

", "time": "2025-07-21T16:48:38Z"}, {"author": "Amaury Chamayou", "text": "

@Christian agreed, but that's ultimately down to the identity of the issuer, as Emil said earlier, and there are many such properties

", "time": "2025-07-21T16:49:30Z"}, {"author": "Sophie Schmieg", "text": "

The only way to get additional security properties is by having the signing party to keep a log of signed hashes

", "time": "2025-07-21T16:49:43Z"}, {"author": "Sophie Schmieg", "text": "

Then the forgery attack on RSA matters for example

", "time": "2025-07-21T16:50:08Z"}, {"author": "Jonathan Hammell", "text": "

Jonathan Hammell said:

\n
\n

If you are doing Sign then Encrypt, if the channel does not provide confidentiality protection, you leak the plaintext.

\n
\n

Nevermind, I'm thinking of the opposite.

", "time": "2025-07-21T16:50:17Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hammell said:

\n
\n

If you are doing Sign then Encrypt, if the channel does not provide confidentiality protection, you leak the plaintext.

\n
\n

I mean, sure, a badly implemented signer could do all sorts of bad things. I think your sign-then-encrypt case applies equally to pre-hashed and direct-sign cases?
\nI'm still not convinced that the verifier of a signature has any business auditing internal implementation details of the signer.

", "time": "2025-07-21T16:50:44Z"}]