On Mon, 24 Jun 2024 at 22:21, Orie Steele <[email protected]> wrote:
> I replied to Ilari offlist by accident, but I hope he will clarify some of > the comments he made regardless. > > I just stumbled across this: > https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/200#issuecomment-2183701761 > > Which seems relevant to his comment about HPKE AuthMode at the end. > HPKE AuthMode is not compatible with PQC and I don't see a benefit of temporarily supporting it with ECDH. -Tiru > > Regards, > > OS > > On Sat, Jun 22, 2024 at 3:42 PM Ilari Liusvaara <[email protected]> > wrote: > >> On Sat, Jun 22, 2024 at 12:32:42PM -0500, Orie Steele wrote: >> > Hello, >> > >> > I've created yet another prototype HPKE implementation to consider >> feedback >> > we got from the adoption call. >> > I know folks are struggling to follow along with HPKE details, but I'm >> > going to address several points of feedback in this email to avoid >> creating >> > separate threads for each topic. >> > To make this bearable (bearer token joke), I have focused only on >> compact >> > JWEs for use as JWTs. >> > >> > As you can see from: >> > >> https://github.com/transmute-industries/hpke/blob/main/tests/jwt.test.ts#L26 >> > >> > In the prototype, JWTs are built from { alg: >> > 'HPKE-Base-P256-SHA256-A128GCM', enc: 'A128GCM' } >> > The encapsulated key goes into the JWE Encrypted Key. >> > This is a change from the draft-ietf-jose-hpke-encrypt-00 where the "ek" >> > was placed in the protected header. >> > It eliminates double base64url encoding. >> > The enc value is set to `A128GCM`, this is a change from >> > draft-ietf-jose-hpke-encrypt-00. >> >> Redefining what enc: 'A128GCM' means in JWE is not acceptable. >> >> Any extensions to JWE itself must encode to currently invalid things >> (but compact and JSON serialization may still be used). >> >> And then alg: 'HPKE-Base-P256-SHA256-A128GCM' sounds like Key >> Encryption... And JWE is pretty explicit on how that works. >> >> >> > Another exciting topic has been AuthMode and PSK support. >> > >> > draft-ietf-jose-hpke-encrypt-00 requests psk_id and auth_kid headers to >> > support this use case, but does not request algorithms. >> >> For PSK, easiest would be to have presence of psk_id header to select >> PSK mode. >> >> - Senders have to be explicitly configured about PSK to use anyway. >> - Receiver not supporting PSK will get decryption failure anyway. >> >> Auth is rather nasty can of worms. It is trivially insecure in >> presence of multiple recipients, and still has security issues >> even with one recipient (because HPKE fails Insider-Auth). >> >> >> > I've now done a first attempt here: >> > >> https://github.com/transmute-industries/hpke/blob/main/tests/jwt-auth-psk.test.ts >> > >> > The headers "psk_id" and "auth_kid" should be optional, but I believe >> it >> > is important to distinguish "auth mode psk" from "base" mode: >> > >> > - HPKE-Base-P256-SHA256-A128GCM >> > - HPKE-Auth-P256-SHA256-A128GCM >> > - HPKE-AuthPSK-P256-SHA256-A128GCM >> > - HPKE-PSK-P256-SHA256-A128GCM >> > >> > This is sad, because it will result in registry bloat per mode. >> > >> > We could consider making the "mode" a dependent parameter of the >> algorithm, >> > but then we lose the ability to distinguish keys which support auth mode >> > from those that do not. >> >> This sounds bit similar to ECDH-SS. While JOSE does not have that, COSE >> does. What does COSE do with ECDH-SS sender keys? >> >> And then one might want to restrict keys to HPKE, but no further. >> >> >> > Now seems like a great time to talk about use cases for HPKE based >> JWTs, so >> > we know which algorithms are actually needed. >> >> For base mode, the only algorithms that JWE has no substitute for is >> the post-quantum stuff. >> >> Yes, HPKE might be a bit more compact, but I doubt people seriously >> golfing bytes are using JWTs. >> >> >> > As you can see, the latest editors copy includes some guidance on use of >> > HPKE: >> > >> > >> https://paulbastian.github.io/draft-bastian-dvs-jose/draft-bastian-dvs-jose.html#name-designated-verifier-signatur >> > >> > If this document were to register algorithms there would be substantial >> > overlap with HPKE Encrypted JWT use cases. >> > >> > I believe that draft-ietf-jose-hpke-encrypt based JWTs can support the >> use >> > case that draft-bastian-jose-alg-ecdh-mac is targeting. >> >> >> HPKE auth mode has property that compromising receiver key allows >> unlimited forgery. >> >> And looks like to enable unlimited forgeries from a single sender, it >> requires leaking just a single DH result (receiver private key times >> sender public key). >> >> >> >> >> >> -Ilari >> >> _______________________________________________ >> jose mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
