[Servercert-wg] [cabfpub] Interest in Ed25519 and/or Ed448?

[Ryan Sleevi]

On Thu, Mar 26, 2020 at 3:40 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Thu, Mar 26, 2020 at 02:56:16PM -0400, Ryan Sleevi wrote:
> > On Thu, Mar 26, 2020 at 1:40 PM Kurt Roeckx <kurt at roeckx.be> wrote:
> >
> > > Ed25519 and Ed448 are not new. They exist now, have many
> > > implementations. It does not require a huge amount of research
> > > or effort to implement it. And it's a clear improvement over
> > > the currently supported algorithms.
> > >
> >
> > Hi Kurt,
> >
> > Of course they're new (to be permitted), or we wouldn't be having this
> > discussion. And they're not a clear improvement over the currently
> > supported algorithms, or else they'd be PQ. I realize we'll likely
> disagree
> > on both of these points, but frankly, the incremental value these
> > algorithms provide (assuming you don't believe I'm an NSA mole hired to
> > shill for P-256) is not worth the significant effort involved.
>
> You're saying it's "not a clear improvement", but at the same time
> has an "incremental value".
>

These aren't mutually incompatible. It can have incremental value, with
significant tradeoffs, that make it unclear if it's an improvement over the
status quo given those tradeoffs.


> > You've
> > shifted the argument somewhat, in that it's ignoring the previous remarks
> > pointing out the dependencies and challenges, so I doubt there's much
> more
> > useful discussion to be had here. Switching to Ed25519/Ed448 for leaf
> > certificates only doesn't achieve any of the necessary security
> > improvements.
>
> I guess the key word there is probably "necessary". Where you
> think PQ is necessary. And I agree that we need it, but we just
> currently don't have it. But that shouldn't stop us from improving.
>

No, I'm not shifting this to PQ.

If the belief is that Ed25519/Ed448 is strictly better than RSA or
P-256/P-384, from a security perspective, then that security value is only
achieved if and only if the entire chain is at that level. If you're having
to mix algorithms, your effective security strength of the chain is only as
strong as your weakest link, and partial transitions don't achieve the
necessary strength. That's no different from mixing SHA-1 and SHA-256.

So unless you can have the whole chain, it's a bold claim to assert it's a
security benefit. And it's been pointed out, in the previous discussions,
why getting the full chain is challenging.


> > and switching for intermediates simply does not provide the
> > necessary trust assurances regarding key generation and protection. This
> > hasn't changed since that previous discussion in any meaningful sense
>
> I have no idea what you mean here. Like I pointed out, there
> are multiple HSMs available.


And as has been pointed out in the past discussions, it's not simply a
matter of "multiple HSMs available". This is reflected in the minutes I
shared with you previously. Consider, for example,
https://smartfacts.cr.yp.to/analysis.html . Or consider discussions about
key zeroization, which is often skipped in non-FIPS modes because of
performance. You're assuming the necessary definition was "in an HSM", but
that's not and never been the goal here.

It's reasonable to say I don't understand. It's not reasonable to use that
confusion to make a bold claim about FUD.


> And if the demand is there, there
> will be others. The only thing I've read so far about this from
> you seems to be FUD to me.
>

That's a bold claim, but highlights why this conversation is now over.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200326/d1945d00/attachment.html>