[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 09, 2024 at 11:11:19AM -0700, Les Hazlewood wrote:
> >
> > This is also prohibited by draft-ietf-jose-fully-specified-algorithms
> > (It requires what alg to be independent of enc).
> >
> 
> Hi Illari,
> 
> 
> Thanks for the explanation, I appreciate it.
> 
> 
> However, I think this is a huge mistake.
 
I consider any strong coupling between enc and alg to be a huge mistake.


> 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.


> Respectfully, this is incredibly regressive.  Data models *should* reflect
> the best-case modeling scenario, with rich expression, modularity, etc.  If
> a new “single string alg” concept needs to exist for downstream
> specifications and/or convenience, *those* specification working groups
> should define such and not impose this on the JOSE/COSE specifications at
> large.  It’s crippling and will forever impact how any algorithms and their
> potential parameters are defined in the future, and just doesn't make sense
> to be forced on a general-purpose messaging format.

Unfortunately here delegating bulk encryption does impose chagnes on JOSE
specifications at large.

(COSE is much more flexible, so no changes to COSE are needed.)
 
 
> Additionally, such an initiative breaks the concepts of `alg` and `enc` as
> they are defined today.  They are and always have been separate
> concepts.  `alg`
> is a *key* management algorithm, it is not an encryption algorithm.  That
> HPKE is composed of both operations isn’t a reason to force it into the
> existing `alg` construct - that's trying to do too much and force things
> that don’t make sense in a single header parameter that has been
> well-defined for a decade.

This is all manmifestation of the way JOSE is designed.

 
> 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.


> Although anecdotal, I will say that not once in 10 years of maintaining
> probably the most-used JOSE/JWT library for the JVM and Android has anyone
> 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.

 
> 
> 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’m not saying that cipher suite negotiation isn’t valuable.  I’m saying
> it’s 1) only valuable to a relatively small set of use cases and 2) is
> easily obtainable by looking at existing headers and 3) it’s fundamentally
> regressive to a) shoehorn a new composite algorithm into a header that was
> never designed as such and b) force *all* JOSE implementations to operate
> with this concept when it’s not needed most of the time.

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).




-Ilari