[secdir] Re: Secdir last call review of draft-ietf-jose-fully-specified-algorithms-08

[Kathleen Moriarty <[e-mail]>]

Hello Mike!

Sent from my mobile device

> On Mar 31, 2025, at 1:15 PM, Michael Jones <[e-mail]> wrote:
> 
> Any thoughts, Kathleen?  We'd like to update the draft to incorporate your feedback before the telechat.
> 
>                Thanks,
>                -- Mike
> 
> -----Original Message-----
> From: Michael Jones <[e-mail]>
> Sent: Wednesday, March 26, 2025 5:46 PM
> To: Kathleen Moriarty <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Secdir last call review of draft-ietf-jose-fully-specified-algorithms-08
> 
> Hi Kathleen,
> 
> Thanks for your review.  We have a mitigation for your first issue.  But before we add it to the draft, I wanted to better understand your second issue.

Thank you for your considerations on the comments. I’ll respond in line to shed a bit more light.
> 
> Are you saying that an attacker could vary the algorithms used when signing content?  That's of course true, but the attack scenario is not clear to me.  Are you saying that an attacker might be identifiable from the algorithm it chooses to use and that by changing algorithms, they could somewhat obscure their identity?  Can you describe an example of a scenario where this could occur in practice, so I can better understand it?

Yes, this attack would apply to any polymorphic changeable set of algorithms. I’m only stating that you should acknowledge it in the security considerations, but I don’t think that there’s a way that you can fully address it. This is more to raise awareness and then someone like OWASP can help more.

If the signature on the content sent changes any signature based detection methods would fail. One suggestion to put in the security considerations would be to suggest a focused on allow listing as opposed to deny listing where you might highlight any indicators of compromise that have been seen before in other attacks. In using an allow list if an organization we’re going to screen on content, they would be permitting what they expect to see. It’s usually a much shorter list and more effective. 

I’m not asking for a lot here just a couple of statements really to highlight a potential concern. Does that make sense and help?

Thank you,
Kathleen

> 
> Also, as you wrote, this consideration applies whether the algorithms are fully-specified or polymorphic.  So it seems like it may have broader application than the specific algorithms defined in this document and this documents advice to avoid polymorphic algorithms.  Does it, for instance, apply to all of JOSE and all of COSE and all of X.509?  Without understanding the attack better, I can't tell.
> 
>                Thanks,
>                -- Mike
> 
> -----Original Message-----
> From: Kathleen Moriarty via Datatracker <[e-mail]>
> Sent: Tuesday, March 25, 2025 5:33 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Secdir last call review of draft-ietf-jose-fully-specified-algorithms-08
> 
> Reviewer: Kathleen Moriarty
> Review result: Has Issues
> 
> Greetings!
> 
> Sorry for my late review. In reviewing the draft, there are 2 easily resolvable findings. The first is that the term "cross mode" is used and never defined.
> Tracing back to the reference provided, the closest I could find to "cross mode" was the following text in RFC 9459:
>   "To avoid cross-protocol concerns, implementations MUST NOT use the
>   same keying material with more than one mode.  For example, the same
>   keying material must not be used with AES-CTR and AES-CBC."
> Matching the language or proving a definition would help to resolve this concern.
> 
> Second, as I was reading the draft, anther security consideration became clear and should be added. An attacker can easily avoid fingerprinting detection or signature detection by rotating the ciphersuite whether it be defined or polymorphic. If programmed to rotate, then the results will look different.
> Awareness of flexibility in protocols to conduct attacks should be explicitly stated so that OWASP can write up mitigations sooner rather than later when attacks become prevalent.
> 
> Thank you for addressing the concerns! I did check the has issues, but do think these are very easily addressed.
> 
> Best regards,
> Kathleen
> 
> 
>