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]
