Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 18, 2019 at 01:39:56PM +0000, Stephen Farrell wrote:
> 
> On 18/12/2019 13:24, John Mattsson wrote:
> 
> Since I didn't get a substantive response on the list,
> I'll repeat:
> 
> "Urgh. Why do we always need to define every possible
> option even though there's no real demand? There are
> already far too many combinations of modes and suites
> in hpke."
> 
> Having more or less finished my implementation now, I
> feel more strongly that additional combinatoric mess
> is a bad plan. Removing options/simplifying would be
> far better.

I do not see combinatoric mess. In fact, trying to "simplify" by
eliminating combinations could very well _increase_ complexity due
to some actual combinatorial mess. 

What can not be done is taking various axes, multiplying the
number of points and taking the resulting product as some kind of
metric of "complexity". In many cases, the sum is better metric than
the product.

Remember the SSL 3.0/TLS 1.0-1.2 ciphersuite mess? That was result
of trying to enumerate combinations. If you think it looks bad, it
is even worse to implement... Even restricted only to recommended
ones.

That said, I would drop NIST P-521 (as seems pretty much everybody
is using NIST P-384 instead).

Then SHA-512 is on-the-fence: SHA-384 is likely more than strong
enough, but SHA-384 is not strength-matched with Curve448 (assume
P-521 gets dropped), while SHA-512 is. And having SHA-256, SHA-384
and SHA-512 is very little additional complexity on top of SHA-256
and SHA-384.

If one wanted combined curve/hash pairs, I would have:

NIST P-256 with SHA-256
NIST P-384 with SHA-384
X25519 with SHA-256
X448 with SHA-512

However, this may be bad idea from complexity standpoint (it
does not reduce complexity very much if at all).

Combining groups with ciphers is definitely a bad idea from
complexity standpoint.

> We (CFRG) could punt on this by using existing IETF
> IANA registries instead of creating new ones. There is
> an almost fine match between what we need and some
> existing registries (if one squints just a little;-)
> that'd remove all this wrangling from our plate and
> that could result in the hpke RFC having only one MUST
> implement kem, kdf and aead. Additional options could
> then be haggled over in the IETF each time someone
> claims a need before subsequently being ignored by
> almost all implementers and an even higher proportion
> of deployments;-)

What registeries?

For groups there is the TLS groups, which actually has only four
recommended entries (P256/384 and X25519/448). Unfortunately it
has variety of less-than-cute stuff (not all of that banned in TLS
1.3) marked not recommended. Bonus points for having 3 entries that
are duplicates except one is banned in TLS 1.3 and one is not.

Then for ciphers, there is TLS ciphersuite registry for TLS 1.3
ciphers. That one combines hashes, sometimes in bit cryptographically
"interesting" ways. It also recommends AES-128-CCM, which is not great
(as it is associated with IoT stuff), plus has already got some less-
than-cute stuff (including NULL ciphers and 64-bit tags) marked not
recommended (with more less-than-cute stuff pending).

And both of these registeries are expert review, so they tend
to accumulate variety of stuff.


And future problem point is if someone lobs in some post-quantum key
exchange stuff. Which will work somewhere between poorly and not at
all. And post NISTPQC, that can very well have Recommended set.



-Ilari