Re: [CFRG] DAE for HPKE, was Re: I-D Action: draft-irtf-cfrg-dnhpke-02.txt

[Ilari Liusvaara <[e-mail]>]

On Mon, Oct 02, 2023 at 08:52:48AM -0400, Richard Barnes wrote:
> EKR - I think the point is less procedural / adversarial than you're
> thinking.  The point of this thread is more seeking feedback for the
> experts on how to interpret the text in RFC 9180.
> 
> So the question for the RG is -- Are folks OK with values being registered
> that do not meet the security requirements in the RFC?  Or does
> Specification Required truly mean that anything that is written down is
> OK?  Note that the expansive interpretation here would allow obviously
> insecure things, e.g., null ciphers or ROT13.  (Not saying this request is
> so obviously insecure, but it doesn't meet the RFC's security bar, and we
> should create a new, undocumented bar, so we're left with no bar.)
> 
> My personal analysis is that the expansive interpretation is risky,
> especially if we broaden the lens to CFRG more broadly.  In recent years,
> there has been a positive trend toward making crypto tools harder to misuse
> -- nonce-reuse-resistant AEAD, more rigid elliptic curves, etc.  In
> algorithm-agile schemes like HPKE, allowing algorithms that are not safe in
> context goes against this trend.  You wouldn't be able to have confidence
> your PKE is secure just because you're using HPKE with a registered
> algorithm, you would have to do a bunch of secondary research to verify
> that the algorithm is good.  This degrades the value of all the good
> vetting that CFRG does, because the consumer is left with uncertainty as to
> whether a given construction is safe.  My evaluation in this case is to
> avoid heading down this particular slippery slope.

In my view, there are two distinct kinds of trouble:

1) Algorithms that are just broken and insecure. 

2) Algorithms that do not provode expected properties in constructions
used.

Obiviously, it is not possible to perfectly avoid the first kind, since
algorithms can go SIKE (or go bad in less dramatic fashion), but being
conservative avoids most of these.

The second kind can still be very nasty landmines. There have been
many cases of critical security vulnerabilities arising from using
algorithms that fail to have expected properties (even if such
algorithms are not in any way weak).

In general, it is very bad idea to mix algorithms with different
properties under a single interface.

To archive expected properties for present HPKE interfaces, one needs
IND-CCA2 (modulo some unexploitable pathological stuff).

I think it is impossible to add support for unreliable multi-message
to the present HPKE interfaces without running into trouble of the
second kind. Therefore, to add unreliable multi-message, one would need
to add new interfaces. And that is much more involved operation than
just registering new algorithms.




-Ilari