Re: [jose] [COSE] Call for Adoption: draft-ajitomi-cose-cose-key-jwk-hpke-kem

[Orie Steele <[e-mail]>]

Thank you for this wonderful breakdown!

On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <[e-mail]>
wrote:

> So three distinct uses of algorithm ID out on the table here:
>
> *1) Header Parameter*
>
>    - Alg used to sign or encrypt and thus what to use to verify and
>    decrypt
>    - Used in COSE_Sign, COSE_Encrypt…, COSE_Signature, COSE_Recipient
>    - Header Parameter label == 1
>    - Not the same as alg COSE_Key (parameter label == 3)
>
> Important point, when both are present, are there any examples of them
being different (aside from the tag) ?
AFAIK they are meant to be matched against, and so, they are meant to be
the *same* when both are present.

>
>    - Seems to be optional. I can’t find anything making it mandatory in
>    RFC 9052. Here’s the CDDL "Generic_Headers = ( ? 1 => int / tstr,  ;
>    algorithm identifier”. It would be a bad idea to leave it out, but that
>    seems to be allowed, perhaps to accommodate extremely low bandwidth uses
>    where the algorithm is known by other means.
>    -
>    https://www.rfc-editor.org/rfc/rfc9052.html#name-common-cose-header-paramete
>
>
>
I agree it is optional, for comparison, here is the JWE reference:
https://www.rfc-editor.org/rfc/rfc7516#section-4.1.1

> *The encrypted content is not usable if the "alg" value does not
represent a supported*
*   algorithm, or if the recipient does not have a key that can be used
with that algorithm*.

Similar to the examples discussed in:
https://datatracker.ietf.org/doc/html/rfc9052#appendix-A

A sender could omit the "alg" from the JWE header, and receiver could
discover alg from "kid" in keys they hold already or via negotiation, but
perhaps that is a better question for the JOSE WG.

I will add them here, since we are discussing JWE / JWK as they might be
impacted by decisions made about HPKE Public Key structure and algorithm
naming / conventions.

*2) COSE_Key Parameter*
>
>    - Alg used to restrict key use of a particular COSE_Key
>    - Used only on COSE_Key
>    - The required purpose of this is restriction of key use
>
> Yes!

>
>    - COSE_Key Parameter label == 3
>    - Definitely optional. "If this parameter is present…”  CDDL:
>    "COSE_Key = {... ? 3 => tstr / int,        ; alg
>
> Agreed ( I still think unrestricted keys are a bad idea ).

>
>    -
>    https://www.rfc-editor.org/rfc/rfc9052.html#name-cose-key-common-parameters
>
>
>
Another note on "sender" vs "recipient" framing, per
https://www.rfc-editor.org/rfc/rfc9052.html#section-5.1

> Examples of header parameters about the recipient are the *recipient's
key identifier* and the *recipient's encryption algorithm*.

In the current COSE HPKE, by the naming of "hkc algorithm parameters" /
"sender info", we are positioning them as originating from the sender's
preferences, but the COSE RFC frames them as meeting the
"recipients preferences"...  and notes that there are security
considerations with sender and receiver agreement.

And per the current HPKE COSE security considerations:

> HPKE assumes the sender is in possession of the public key of the
recipient and HPKE COSE makes the same assumptions.  Hence, some form
   of public key distribution mechanism is assumed to exist.

Combined with the following from RFC9180:

> HPKE assumes that the sender and recipient agree on what algorithms to
use.

- https://www.rfc-editor.org/rfc/rfc9180.html#section-9.7.2

When we say "public key" in a CRFG document, I think it is reasonable to
assume no specific representation (JWK, COSE Key, PGP, etc...)

As a side note, HPKE requires more than just having a recipient public key,
it also requires knowledge of the recipient supported algorithms... (this
is extremely obvious per the security considerations).
It is natural to assume this will be solved differently in COSE, PGP,
etc...
Maybe it is in the key representation, maybe it is via negotiation, as you
mentioned earlier...

But it has to actually be solved for, or the sender is just guessing that
the recipient will be able to process their messages.

When we say "public key" in a COSE WG document,
folks will want to be sure if we are talking about the "abstract concept of
a public key"
or a concrete serialization conforming to normative requirements (JWK
Public Key or COSE Public Key).

Holding a JWK or COSE "public key" with an algorithm, 🔥 has historically
meant 🔥 holding a recipient's encryption preferences.

- https://datatracker.ietf.org/doc/html/rfc9052#appendix-B
- https://www.iana.org/assignments/cose/cose.xhtml see (-27).

There is no precedent for COSE Key or JWK containing "preferences for
parameterization" in addition to a "restriction of key use".

You can imagine COSE HPKE asking IANA to update the COSE registry to
communicate that "hkc" is bound to a specific value of "alg", similar to
how -27 is bound to "kty".
(! 🔥 kty and alg confusion intensifies... )

... I prefer to imagine requesting registration of a few good choices for
HPKE COSE (to start), and not importing every option under the sun by
default from the CFRG established registries here:

https://www.iana.org/assignments/hpke/hpke.xhtml

For example, we could register Apple's preference like in
https://www.iana.org/assignments/cose/cose.xhtml, just like this:

APPLE-HPKE-v1
<https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036918>
(really
TBD) |  -27 (really TBD) | DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 +
AES-128-GCM
<https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036908>...
(0x0010, 0x0001, 0x0001)
<https://www.iana.org/assignments/hpke/hpke.xhtml> [kty]
| [draft...HPKE-COSE
<https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/>] | Yes

Later, if DHKems are broken by quantum computers, we change the "Yes" to a
"No"...

How many other preferences would we need to register? Only the ones people
actually want to use, and *they* need to do *some* work to justify why this
is a good idea...
we don't just hand out a blank check, and leave COSE implementers on the
hook for an ever expanding bill of CFRG registered algorithms.

Obviously Apple is just an example here... But I suspect people will end up
referring to HPKE configuration by names sooner or later,
"APPLE-HPKE-v1" is already easier to pronounce than "HPKE-v1-BASE + (
0x0010, 0x0001, 0x0001) <https://www.iana.org/assignments/hpke/hpke.xhtml>"
.

If we make this harder, people will just call it what Apple calls it...
Since Apple is already following a best practice here, and it is easier to
understand what is supported from their simple and effective choice of a
name... for what is supported.

HPKE is not actually usable in COSE without some work from this working
group,
we should not defer our responsibility to the (first ever, IIRC) CFRG
established registry,
it is not going to feel good for developers, if we try to start a 5 guy
revolution while the world is trying to upgrade to post quantum encryption.

*3) Algorithm negotiation*
>
>    - RFC 9052 defines no protocol message for negotiation
>    - It doesn’t even require that items in the COSE algorithm registry be
>    used for negotiation, though that seems like a very good and obvious thing
>    to do
>    -
>    https://www.rfc-editor.org/rfc/rfc9052.html#name-application-profiling-consi
>
>
>
As you noted, there will be cases when you want to use COSE HPKE, without
holding a JWK or a COSE Key... or via some negotiation for one...
The good news is that you can still do that with a named algorithm, Apple
provides an example of this today.
I suspect we will see more examples if COSE HPKE becomes an RFC.


> Up until COSE_HPKE, 1) and 2) are a single integer ciphersuite. Probably
> anyone doing 3) up to until COSE_HPKE would also use the single integer too.
>

Agreed.


>
> draft-ietf-cose-hpke has addressed 1) with the new HPKE_sender_info header
> parameter. Now the algorithm used is a special ciphersuite identifier that
> indicates further details in an additional parameter.
>
>
Agreed, there are "proposals for revolution", which I am all for, if they
are coming from enough reviewers / implementers.
I am happy to withdraw my objection if overwhelmed by counter arguments, I
don't find the current arguments from Ilari compelling, but I appreciate
his consistent engagement.


> draft-ajitomi-cose-cose-key-jwk-hpke-kem is a proposal for 2) COSE_Key
> using the same approach as draft-ietf-cose-hpke, but a slightly different
> structure. It uses HPKE_Key_Configuration which different
> from HPKE_sender_info by not having the enc item.
>
> draft-ajitomi-cose-cose-key-jwk-hpke-kem is also a proposal for 3).
>
> Take-away is:
> - Algorithm ID is always optional in COSE and should always be optional in
> COSE_HPKE. We can write tons of security considerations to say why that is
> bad, but we shouldn’t change COSE fundamentals.
>
>
💯 This has been my consistent argument.


> - In COSE_HPKE we’re requiring algorithm identification be made up of a
> special ciphersuite and a triple. This will/should apply in all contexts
> where COSE algorithm IDs are used.  Maybe we should try to unify the
> definition of this in draft-ietf-cose-hpke
> and draft-ajitomi-cose-cose-key-jwk-hpke-kem?
>
>
I don't think we need another document.

I think we should bend the knee to convention in COSE HPKE, even over the
objections of Ilari and Daisuke... (assuming they persist in advocating for
parameterization of alg).

UNLESS, we have clear consensus on proceeding with a revolution, for that I
would want to see a lot more engagement :)


>
> My opinions on 3) are:
> - The use cases are too widely varying for anyone to define an actual
> protocol
> - draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a small
> fraction of negotiation use cases — those that use COSE_Key for negotiation
> - We might generalize the HPKE COSE algorithm identifier definition so the
> same thing can be used for 1), 2) and 3).  That is probably splitting HPKE_sender_info
> into two, one structure that is the algorithm ID and one is the enc info.
> We still wouldn’t define actual protocol for 3) but we would have a clear
> common method for COSE HPKE algorithm identification that anyone could use
> for their use-case specific negotiation protocol.
>
>
I agree with you on 3.


> LL
>
>
>
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>