On Wed, Jul 10, 2024 at 09:17:01AM -0700, Les Hazlewood wrote:
> >
> > I consider any strong coupling between enc and alg to be a huge mistake.
> >
>
> They are already strongly coupled. The properties of the enc algorithm
> (minimum/mandatory key size) must be known for the key management (alg)
> behavior. If they were actually independent, alg wouldn't need any
> enc-based input parameters.
That is not strongly coupled. Strong coupling would be things like
affecting the algorithms used, or worse, monkeypatching alg behavior.
To implement the current behavior, one only needs one of:
- Bulk cipher -> key length mapping.
- Pass the length as parameter outright.
> > > The entire purpose of JOSE is to have a JSON-compatible metadata format
> > for
> > > message sending and receiving; with all the flexibility, convenience,
> > > expressiveness and human-readability that implies, which is a really good
> > > thing, and solidifies the ability to be flexible over time, which is
> > ideal
> > > for an RFC.
> >
> > Unfortunately, here one runs into limitations of JOSE: One would want to
> > delegate bulk encryption, which is not something JOSE (or any trivial
> > extension thereof) supports.
> >
>
> Not today at the moment, but as these things would imply new (additive)
> header parameters, this could be true. It wouldn't be regressive since it
> does not change the purpose and semantics of existing header parameters.
>
> But I do understand and respect what you're saying about delegation and the
> associated difficulties of a new paradigm.
None of existing JOSE modes can delegate bulk encryption. So however is
it signaled, it still requires a new mode, which is a big deal and
requires updating RFC7516.
> > Any new specification that defines a single string cipher suite definition
> > > should be *additive*, not regressive. A new header could be defined
> > (e.g.
> > > `csuite`) and that can have that string for the times when it may be
> > needed.
> >
> > Or have "enc":"dir" and have that call into new algorithm operations.
> >
>
> This fundamentally changes the semantics of the existing headers. In JOSE,
> for 10+ years:
>
> "alg" has always meant "algorithms used for producing the content
> encryption key"
> "enc" means "AEAD algorithm used to encrypt the content with the content
> encryption key"
>
> Changing these semantics has *significant* implications to existing
> libraries, especially typesafe ones that codify these concepts in type-safe
> APIs used by application developers (Key types, Interface definitions, etc).
There is no way to delegate bulk encryption without fundamentally
changing semantics. The implementations need to special-case that in
very fundamental ways.
For example, currently it is possible to define decrypt_recipient_cek() that
works with any alg. That can not support delegating bulk encryption: One
needs whole another path to handle decrypting integrated encryption.
On encrypt side, one currently needs two paths (encrypt a CEK and derive
a CEK). Integrated encryption would be third path.
>From incomplete prototype I have written, in decrypt_recipient_cek():
//Integrated encryption is not supported, as it does not have a CEK.
if enc == "dir" { return Err(RecipientError::IntegratedEncryption); }
(encrypt_recipient_cek() and derive_cek() have similar check.)
> > ever had a problem with separate `alg` and `enc` headers, and that
> > includes
> > > all the OpenID Connect scenarios I’ve supported both professionally and
> > as
> > > an open-source maintainer.
> >
> > JOSE is designed to work that way, so not really surprising nobody had
> > problems.
> >
>
> Yes, but this is the JOSE working group, designed for JOSE messages, and
> supported by JOSE implementations. I'm having a hard time understanding
> why a JOSE HPKE RFC would change a decade of semantics and convention when
> the existing parameters can still be used as intended, and/or new
> parameters can be introduced.
The changes are much more fundamental than what new parameters can do.
> > > Or if a new header isn’t desired, there’s no reason an additive
> > > specification can’t say “If you want a single string, combine the `alg`
> > and
> > > `enc` header with a hyphen, and that’s your cipher suite”. To say that
> > an
> > > implementation - which *must* parse the JSON header and lookup at least
> > one
> > > parameter (`alg`) anyway - cannot lookup another header and concatenate
> > the
> > > two before processing that value doesn’t seem to hold water in any
> > scenario
> > > I can think of. That’s all that’s needed for cipher suite negotiation
> > for
> > > protocols that need a single string.
> >
> > That is not injective.
> >
>
> I don't understand why that must be a requirement of a JOSE RFC - it's
> trivial logic and can be codified in the RFC.
It is valid to have:
alg:foo
alg:foo-bar
enc:zot
enc:bar-zot
What does ciphersuite "foo-bar-zot" mean?
> > The only constraint on negotiation from "enc":"dir" would be that
> > Integrated Encryption must be supported for all or none of the supported
> > algorithms (that allow IE).
> >
>
> "dir" is not an AEAD algorithm. Per
> https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2:
>
> "This algorithm MUST be an AEAD algorithm with a specified key length."
Yes, and that turns out to be a critical security requirement.
Better to do something that is guaranteed to blow up existing
implementations than something existing implementations could try to
process in who-knows-what ways.
> I'm personally worried about changing 10 years of semantics due to the
> downstream impact that will have on implementations.
>
> Even though this is a challenging problem, I'm still very hopeful that a
> good solution is achievable.
Oh, impact on implementations is the #1 worry about HPKE in JOSE I have.
And the problem with prototypes is that it is easy to take shortcuts
that hide the problems a serious implementation would encounter.
-Ilari
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
