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

[Mike Ounsworth <[e-mail]>]

Mike,

Do I get the honour of being your first author who decided to treat a
COMMENT as a DISCUSS?

-18 hopefully does what you want. (there's also a diff in there related to
a discussion with Samuel Lee)

https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-pq-composite-sigs-17&url2=draft-ietf-lamps-pq-composite-sigs-18&difftype=--html

I just noticed a typo in the new text "by by using". I'll fix that on
github, but not worth a -19.


On Thu, 9 Apr 2026 at 15:09, Mike Bishop <[e-mail]> wrote:

> 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]> 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]>
> *Sent:* Wednesday, April 8, 2026 8:41 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)
>
> 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]>
> 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]
> To unsubscribe send an email to [e-mail]
>
>