search

cose-wg / HPKE

3 stars 3 forks source link

Ciphersuite selection #29

Closed dajiaji closed 1 year ago

dajiaji commented 1 year ago

Following the consensus call result, it is necessary to select some ciphersuites for the COSE-HPKE spec.

Personally, I think there are the following options:

  1. Adopt the set of cipher suites selected by MLS (Messaging Layer Security) that follows a similar cipher suite approach. It's an easy way for us because we don't have to think about it.

  2. Define a carefully selected set of cipher suites intended for use in COSE. My choices are as follows:

    • HPKE-v1-Base-P256-SHA256-AES128GCM: composed only with NIST selected KEM/AEAD algorithms.
    • HPKE-v1-Base-X25519-SHA256-Chacha20Poly1305: composed without NIST selected KEM/AEAD algorithms.
    • HPKE-v1-Base-X25519-SHA256-AES128GCM: X25519 with an AEAD algorithm which can be hardware-accelerated.
    • HPKE-v1-Base-P384-SHA384-AES256GCM: As an alternative choice for rich environments.
selfissued commented 1 year ago

Do those correspond to these numbers at https://www.rfc-editor.org/rfc/rfc9420.html#mls-cipher-suites : 2, 3, 1, 7? Are you uninterested in 4, 5, and 6 because they use 512-bit operations?

Given that the MLS choices have survived IESG review, we could do worse than to reuse them (or a subset of them).

ilaril commented 1 year ago

Earlier, I did come up with set of 12 cipher suites based on objective criteria.

I would add at least X448 and X25519Kyber768 with Chacha20 and AES256 to that list of 4 cipher suites. X448 being the high-level CFRG curve, and X25519Kyber768 being post-quantum (which is currently the only one with no equivalent in COSE).

Then when CFRG adds DHKEM(CP-256, HKDF-SHA256) and DHKEM(CP-384, HKDF-SHA384), one definitely wants cipher suites based on those. In fact, I think that DHKEM(CP-256, HKDF-SHA256) / KDF1 / AEAD1 should have 1 byte alg value.

dajiaji commented 1 year ago

Do those correspond to these numbers at https://www.rfc-editor.org/rfc/rfc9420.html#mls-cipher-suites : 2, 3, 1, 7? Are you uninterested in 4, 5, and 6 because they use 512-bit operations?

Yes, this is just an example, but my selection above corresponds to the MLS ciphersuite 1, 2, 3 and 7.

Are you uninterested in 4, 5, and 6 because they use 512-bit operations?

At least I thought we could leave them out of the first selection of ciphersuites for COSE. I have not seen any examples of actual use of P521 or X448 in JOSE/COSE either.

Given that the MLS choices have survived IESG review, we could do worse than to reuse them (or a subset of them).

Yes, I think so.

ilaril commented 1 year ago

Three new KEMs (compact NIST curves) were added to the HPKE KEM registry.

The earlier criteria I posted now gives 18 cipher suites (9 KEMs * 2 cipher families).

And I think at minimum, the following two should be defined:

dajiaji commented 1 year ago

@hannestschofenig @selfissued @ilaril @OR13

I had intended to withdraw my narrowed down ciphersuites above if someone raised the need for additional options. I thought it was a possible direction, but it does seem challenging after all.

The 10 ciphersuites chosen by Ilari cover valid combinations in the HPKE specification (RFC9180) and are excellent choices if prioritizing the versatility of COSE-HPKE (covering all seven ciphersuites defined by MLS and adding options for using chacha20 with ECDH KEM, which MLS does not have).

On the other hand, the two ciphersuites using post-quantum hybrid KEMs in Ilari's choices have not yet been standardized by CFRG. It's just an individual draft for now. Therefore, I thought it might be better to create a separate Internet-Draft that could serve as a template for adding new ciphersuites to the COSE-HPKE in the future.

Considering this, I suggest including the following 10 ciphersuites in the COSE-HPKE spec, and making separate drafts for post-quantum hybrid KEMs and DH-KEMs with compact EC curves.

What do you think about it?

OR13 commented 1 year ago

, I thought it might be better to create a separate Internet-Draft that could serve as a template for adding new ciphersuites to the COSE-HPKE in the future.

I agree with this.

The breakdown you have looks good.

I think we should aim for test vectors for every suite and include examples in the appendix.

I'm happy to help on that front.

ilaril commented 1 year ago

Technically, CFRG is not allowed to standardize anything. But I think the comment about post-quantum hybrid not yet being standardized meant it not yet having been published as an RFC. It will never be published as an RFC.

The registry policy is "specification required", which means requiring a stable specification. All entries are assumed to be stable and fully interoperable. HPKE abstracts the differences away.

There is a similar situation with TLS cipher suites, but with much higher stakes.

Being based on objective criteria, the list of 12 cipher suites has become list of 18 cipher suites.

And I still think the post-quantum hybrid and compact curves should be included in the initial document:

hannestschofenig commented 1 year ago

I have added the algorithms mentioned above to the draft. We will definitely have to talk about the algorithm list in the entire group but the current list is a proposal.