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

[Orie Steele <[e-mail]>]

I tend to agree with Ilari, but I would highlight that this is now
essentially a "reputation and naming" issue... not a technical registry
issue.

If you name "HPKE-not-IND-CCA2", HYDE (HYbrid Deterministic public key
Encryption, or some more clever name chosen more carefully to inform users,
of the difference without sarcasm / humor : ), and give it a new
registry...
the name is different, the reputation of both is independent, and the
capabilities of both systems are preserved, including their unique security
properties.

Names, reputation and capabilities matter a lot.

I'd avoid mudding the waters here for HPKE,
but I don't think that should stop people from tackling use cases that need
something that is like HPKE but has different security properties... just
don't call it HPKE, that means new registries.

OS



On Tue, Oct 3, 2023 at 8:37 AM Ilari Liusvaara <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>