On Fri, Sep 01, 2023 at 12:02:50PM -0500, Orie Steele wrote: > On Fri, Sep 1, 2023 at 11:37 AM Ilari Liusvaara <[email protected]> > wrote: > > > Then I think the prohibition of polymorphic algorithms should be scoped > > on signatures. Perhaps it is intended that things like ECDH-ES are not > > polymorphic, but this is not clear. > > > > Fully specifying signatures is both easy to do (as evidenced by this > > draft) and easy to maintain (due to COSE/JOSE having signature > > framework, and things not being prone to combinatorial explosions). > > Also, in JOSE, signatures were originally fully specified. > > > > In contrast, fully specifying asymmetric encryption is much more > > messy affair: There are no frameworks and things tend to combinatorially > > explode. Also, in JOSE asymmetric encryption was not even originally > > fully specified. > > > > > I also agree with this comment, however, as you pointed out previously, > it's possible someone might attempt a cross curve ECDH operation on curves > that share a cofactor... the algorithm restriction would not help protect > them in this case, they would have to look at ephemeral keys or kem_id in > this case right? > > Pulling an example from a JWE Header
(P-256 JWE) > Let's ignore "enc" here. > > If your recipient public key looks like: (P-256 public key) > > This is the "happy case". > > In the case your recipient public key looks like: (X25519 public key) > This is the "sad case". I would think that trying to mix P-256 and X25519 keys would end up causing internal error (X25519 keys do not have "y"!). However, I would have thought that trying to mix RSA public keys and HMAC keys would be even more likely to trigger internal error (RSA public keys do not have "k"). However, somebody managed to make that somehow (in a way I can't fathom) work. > Just for the sake of seeing the opportunity to leverage algorithmic > restriction to mitigate the sad case, if the algorithm where "fully > specified", it might look something like this: > > - ECDH-ES+P-256+A128KW > - ECDH-ES+X25519+A128KW > > ^ is this "worth it" ? I don't think that would improve things: Previously, you had the same thing twice, now you have it trice. > Do we have cases where cross curve ECDH caused problems that "fully > specifying" might have helped mitigate? I don't think there are, because implementations of ECDH are already required to withstand whatever cross-curve ECDH would cause (especially off-curve points). > A quick google search turned up a few potential references worth reviewing: > > > The JSON Web Algorithm (JWA) ECDH-ES KDF construction does not mix > keys into the final shared secret. In key exchange, such mixing > could be a bad mistake; whereas here either the receiver public key > has to be chosen maliciously or the sender has to be malicious in > order to cause problems. In either case, all security evaporates. > > - https://datatracker.ietf.org/doc/html/rfc8037#section-4 > - https://zisc.ethz.ch/wp-content/uploads/2017/02/sanso_jwe.pdf > > I'm not enough of a crypto expert to fully understand if fully specified > ECDH-ES is an improvement or just extra registry entries, for no real value. I don't see any way for fully specifying to help with either of these. Neither requires any disagreement on curves. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
