On Mon, Dec 4, 2023 at 5:29 AM Neil Madden <[email protected]> wrote:
> > > On 1 Dec 2023, at 21:20, RFC Errata System <[email protected]> > wrote: > > The following errata report has been submitted for RFC7516, > "JSON Web Encryption (JWE)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7719 > > -------------------------------------- > Type: Technical > Reported by: Jeffrey Yasskin <[email protected]> > > Section: 6 > > Original Text > ------------- > The key identification methods for this specification are the same as > those defined in Section 6 of [JWS], except that the key being > identified is the public key to which the JWE was encrypted. > > Corrected Text > -------------- > ??? <I don't know the proper correction.> > > Notes > ----- > Section 6 of [JWS] says "these parameters need not be integrity protected, > since changing them in a way that causes a different key to be used will > cause the validation to fail." > > I don't know if this is true for signature schemes (that is, RFC 7515 > might have the same erratum), but this is only true for encryption schemes > if the algorithm is key-committing. See > https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-properties-02.html#name-key-commitment > . > > > It’s technically not true for all signature schemes either. For example, > you can add a point of small order to any Ed25519 public key to obtain an > equivalent (but technically different) public key that validates the same > signatures. (This caused a double-spend bug in at least one cryptocurrency > [1]). > > So I agree with this erratum. What to do about it requires some thought > though. It’s hard for me to grok what the original text was trying to say. > The only time you should ever trust a public key conveyed by the message > itself (to validate that same message) is during a registration process > where you’re just doing proof-of-possession to verify that the entity > actually controls the key they are registering. In all other cases the key > must come from a trusted source, which implies not just data integrity but > also data origin authentication and some means of validating trust in that > key *before* using it to verify the message. > > Otherwise you open yourself up to bugs like this old Cisco one [2], where > an attacker can simply supply their own public key, and message and > signature of their choosing. So it really makes little difference whether > these headers are integrity protected or not. > > I summary, this is a real issue but I don’t think simply requiring key > commitment is enough to fix this issue. I’m not sure exactly what would fix > it. The real error is in RFC 7515 section 6, where I think the entire last > sentence of the first paragraph should be deleted as simply wrong. Then RFC > 7516 doesn’t need any changes (which I guess would mean technically > rejecting this erratum and raising a new one). > > [1]: > https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html > [2]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114 > > — Neil > Thanks for the response! It's probably fine to just delete the incorrect statement as the erratum fix. +1 for that being in RFC 7515 instead of RFC 7516. Would you delete all of "These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail." or just the "however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail." part? It might be nice to also add something to prevent other people from making the same mistake as the RFC authors. Perhaps "Note that some algorithms allow multiple keys to validate or decrypt the same signature or encrypted data."? But it's probably better to have the erratum just delete text if it's going to take a lot of time to find the right replacement text. Jeffrey
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
