On Thu, Nov 17, 2022 at 02:49:47PM -0600, Orie Steele wrote:
> Interested in unpacking The COSE_Key has new *kty HPKE*, and its JWK cousin.
>
> Comments inline:
>
> On Thu, Nov 17, 2022 at 2:02 PM Ilari Liusvaara <[email protected]>
> wrote:
>
> > On Thu, Nov 17, 2022 at 10:05:28AM -0600, Orie Steele wrote:
> > > Illari answered a related question here:
> > > https://mailarchive.ietf.org/arch/msg/cose/eIxt4u8ox8N35-ZbDk_vsFD9PP4/
> > >
> > > I have similar questions on how HPKE, PQC KEMs, and COSE Key work
> > together
> > > in practice.
> >
> > Here is how I think it will work:
> >
> > - The COSE_Key has new kty HPKE, containing the algorithm used
> > (expressed using HPKE KEM identifier), public key blob (bstr),
> > possibly some hints and for private keys, private key blob (bstr).
> > - When encrypting, the COSE-HPKE just passes the HPKE code the KEM
> > identifier and the public key blob from the key (along with other
> > stuff like the plaintext to encrypt). HPKE code knows what to do
> > with those.
> >
>
>
> I would have assumed a slightly different interface, that pulled the
> parameterization from the key representations, for example:
>
> // encrypt
> const sender = HPKE.JOSE.sender.createSenderContext({
> publicKeyJwk: *kty*, ..., x, *alg: Kem.KemKyber1024HkdfSha256 -
> Kdf.HkdfSha256 - Aead.Aes128Gcm* }
> })
> const ct = await sender.seal(new TextEncoder().encode("hello world!"));
>
> // decrypt
> const recipient = HPKE.JOSE.recipient.createRecipientContext({
> privateKeyJwk: *kty*, ..., x, d, *alg: Kem.KemKyber1024HkdfSha256 -
> Kdf.HkdfSha256 - Aead.Aes128Gcm* },
> enc: sender.enc,
> })
> const pt = await recipient.open(ct);
This would result in a nasty combinatorial explosion and a lot of extra
work on the COSE WG, of the kind COSE WG is ill-equipped to do.
> I understand HPKE design focuses on moving the parameterization
> outside of the key representations, and to enable the same public
> or private key to be used in many different ways.
>
> I think that's fine for folks who want that, but when designing APIs
> I prefer to set this in stone at the time of key generation,
> and not invite implementers to use the same key material with many
> different parametrization of algorithms.
HPKE is designed to be able to soundly use the same key material with
multiple algorithms.
> As I understand it, HPKE can support both design philosophies, but
> as we start to register new kty, or alg values, we will be driving
> consolidation towards one side or the other when HPKE is used in
> JOSE or COSE.
I am saying that one of those philosophies WILL lead to a mess.
As for other users of HPKE, TLS ECH went with using key format similar
to what I outlined (but with custom encoding).
TLS did use ciphersuite approach for TLS 1.0 to 1.2. It was a giant
mess with ultimately hunreds of entries. They switched away when they
realized that using traditional ciphersuites for TLS 1.3 would have been
totally unmanageable.
As for "matching strengths", I understand that as purely avoiding
doing unnecressary work in one part that is negated by other part.
Hence, don't use 128-bit Chacha, because it is not faster than 256-bit
Chacha.
Furthermore, comparing strengths of different parts is complicated
by different subtreshold scalings. E.g., 192-level ECDH (quadric
scaling) is good bit stronger than 192-level symmetric cipher (linear
scaling).
> - When decrypting, the COSE-HPKE just passes the HPKE code the KEM
> > identifier and the private key blob from the key (along with other
> > stuff like encapsulated key and the ciphertext to decrypt. HPKE code
> > knows what to do with those.
> >
> > If the KEM is PQC or not is not something COSE-HPKE code needs to
> > concern itself with. Currently HPKE does not have any PQC KEMs, but
> > that could change at any time.
> >
> > As for PQC outside HPKE in COSE, that is obviously more complicated
> > matter, that turns out to need at least some new alg values, along
> > with new (sub)types for the keys. Those things work in way similar to
> > ECDH-ES, however reusing the ECDH-ES codepoints is not possible due to
> > ECDH-ES requiring ephemeral key, which just does not exist for PQC.
> >
>
> Yes, agreed, but I think the developer experience should still be
> considered.
Developer experience is secondary to cryptographic soundness.
And creating a spec that is a complete mess is not conductive to good
developer experience.
My design philosophy is to try to make simplest correct implementation
as simple as possible, and simplest working implementation as close
to correct as possible ("get it right, or it won't work at all").
Hence things like overloading codepoints.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
