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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?

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 <noreply@xxxxxxxx> 
Sent: Tuesday, March 25, 2025 5:33 AM
To: secdir@xxxxxxxx
Cc: draft-ietf-jose-fully-specified-algorithms.all@xxxxxxxx; jose@xxxxxxxx; last-call@xxxxxxxx
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



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux