[lamps] Re: Mike Bishop's No Objection on draft-ietf-lamps-pq-composite-sigs-15: (with COMMENT)

[Mike Bishop <[e-mail]>]

The sources of randomness which meet their operational goals sound severely limited, then. 🙂 The fallback I reference is the "If you really have to reuse keys, at least do this other thing, we beg you" (using an appropriate ctx value).

I agree that the text is largely there; I'm mainly looking to reduce the tacit permission to do stupid stuff. My proposed change would be:

  *
Delete the first paragraph; lead with the justification rather than the RFC6919 keyword
  *
Replace the last paragraph with something like "Using an appropriate... composite signature somewhat mitigates, but does not eliminate, the risks inherent in key reuse."

________________________________
From: Mike Ounsworth <[e-mail]>
Sent: Thursday, April 9, 2026 12:30 PM
To: Mike Bishop <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [lamps] Mike Bishop's No Objection on draft-ietf-lamps-pq-composite-sigs-15: (with COMMENT)

Thanks Mike!

> It MUST be freshly generated, but if there's concern about potential collisions due to limited sources of randomness

Yeah, so the reason behind wanting to bolt an ML-DSA key to an existing RSA key is not to do with limited randomness, but rather to do with process and audits, like, I've heard stories like "We've had this RSA key in production for 85 years, and 35 government officials watched it be generated, and we've syncronized it between datacentres by military briefcase. So bolding an ML-DSA key to it is basically free (ie the audit requirements don't prohibit that), but generating a fresh RSA key requires us to re-do all that expensive and time-consuming ceremony". I'm exaggerating of course, but sadly not by much.

So I'm not sure what you mean by "fallback". We have people who we know are going to do exactly the bad thing and lose basically all of the security properties of this document. I'm not sure what "fallback" means in that context? Does it mean "fall through the floor to your death"?


> If someone's operational constraints dictate disabling core security features of the protocol, you've explained why that's a bad idea and also discussed how to mitigate the fallout.

Have we not done that already in 9.3?

"key reuse MUST be avoided to prevent the introduction of EUF-CMA vulnerabilities."
"In addition, there is a further implication to key reuse regarding certificate revocation. ... Therefore, ..., CAs performing revocation checks on a composite key SHOULD also check..."
"the weakening of security from doing so can be mitigated by using an appropriate ctx value, such as ctx=Foobar-dual-cert-sig to indicate..."


PS -- I am treating this as a DISCUSS because I think it needs to be discussed because Section 9.3 is in fact deeply uncomfortable for exactly the reasons you're raising. And thank you for raising them. If we can improve this text, I'd like to do that.

On Thu, 9 Apr 2026 at 11:08, Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:
I'm thinking of something like https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-28.html#section-14.8, which says "We take this security precaution, because if we didn't, the following attack would work: ... The attack above is prevented because (thing) leads to detection of the attack." You're wanting to hint at a fallback position, so maybe also "Doing (alternative) would reduce the odds of the attack succeeding, but not eliminate it."

That is, document the reason the requirement is there, discuss the fallback, and why it's helpful but not sufficient. If someone's operational constraints dictate disabling core security features of the protocol, you've explained why that's a bad idea and also discussed how to mitigate the fallout.

Another approach might be to phrase it as uncertainty. It MUST be freshly generated, but if there's concern about potential collisions due to limited sources of randomness, this additional step can mitigate the fallout of a collision; if a "collision" is made more likely by someone's operational setup, you've at least helped.

________________________________
From: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 8, 2026 8:41 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] Mike Bishop's No Objection on draft-ietf-lamps-pq-composite-sigs-15: (with COMMENT)

Hi @Mike Bishop

Thanks for the careful review.

I have made these changes here:
https://github.com/lamps-wg/draft-composite-sigs/commit/c2d3ca12014874ab5adbc3a4750ed59e36c54011


I think this COMMENT of yours is really astute and probably actually should be a DISCUSS. So let's discuss ;)


In Section 9.3:

>   designers are aware that some implementers may be forced to break
>   this rule due to operational constraints.  This section documents the
>   implications of doing so.

This statement makes me nervous. Maybe this section should explain why the MUST
exists, and not touch any implied "permission" to violate it?

That section basically says "We are aware that people are going to have to violate the core security requirement of the draft, so let's analyse exactly what happens when you do".
Trust me, it also makes me nervous. Very nervous.
I have a customer in this situation, and trust me, I have tried my hardest to talk them out of it.
The thinking here is that if we can't stop it, then at least we can document what sharp pointy edges you need to watch out for.
Thoughts?

On Wed, 1 Apr 2026 at 09:50, Mike Bishop via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Mike Bishop has entered the following ballot position for
draft-ietf-lamps-pq-composite-sigs-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this work. This is an important step forward in our handling of
PQ crypto.

Section 3.1.1: There are a lot of MAY-examples in this section, when the whole
thing is an overarching "MAY do whatever internally so long as the external is
consistent." Consider not using MAY for every single example.

----

Section 4 has:

>   example, a stand-alone RSA private key can be encoded in Chinese
>   Remainder Theorem form.  In order to obtain interoperability,

Consider an informative reference?

----

Section 6 has:

>   Labels are represented here as ASCII strings, but implementers MUST
>   convert them to byte strings using the obvious ASCII conversions

While they may be obvious, calling them so comes across a bit oddly. Maybe just
say something like "Labels are represented here as ASCII strips, but are octet
sequences when used in..."

----

Consider moving Section 6.2 to an appendix; it's not part of the core protocol,
just design background.

----

In Section 9.1:

>   algorithm security or to provide migration flexibility.  Let's
>   quickly explore both.

It's typically advised to avoid first- or second-person language in
specifications. I'd just drop this final sentence, personally.

----

In Section 9.3:

>   designers are aware that some implementers may be forced to break
>   this rule due to operational constraints.  This section documents the
>   implications of doing so.

This statement makes me nervous. Maybe this section should explain why the MUST
exists, and not touch any implied "permission" to violate it?

----

In Section 9.4:

>   message which happens to start with this string.  The designers
>   accepted this trade-off.

I would remove this last sentence. You've explained the trade-off; it's up to
the implementers to decide whether it's worth making, no?

----

Consider moving Section 10 to an appendix.



_______________________________________________
Spasm mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>