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

[Ryan Sleevi]

I can understand why it's useful to see the problem as "figure out the
unknown unknowns", but I don't think that's relevant/applicable here.

The objective isn't to move to a purely QR system from a classic system,
it's rather that inevitably we need a hybridized approach. The cost and
work of introducing new algorithms does not necessarily go down by
introducing more algorithms; if anything, the inverse is more likely true.

For lack of a better analogy, the parallel I would draw would be the
transitions to TLS 1.1, TLS 1.2, and TLS 1.3. TLS 1.1 did not really
provide a lot of compelling benefit for people to upgrade, and so they
didn't, and it was quite a bit of work to do so. Compare that with TLS 1.2,
which while it languished for a bit, when it did provide a compelling
security benefit (in light of POODLE, BEAST, and the many protocol-layer
attacks), we saw it was much easier for folks to migrate. TLS 1.3 saw rapid
adoption, but it also showed that despite the effort folks put in to
deploying TLS 1.2 securely, there was a significant amount of ossified
assumptions that lead to a huge amount of woes -
https://www.youtube.com/watch?v=_mE_JmwFi1Y

Respectfully, EdDSA is closer to TLS 1.1, while hybrid schemes are closer
to TLS 1.2/TLS 1.3.

This isn't about putting the perfect as the enemy of the good, but rather,
there's finite time and engineering resources, and there are substantial
ecosystem-wide challenges in introducing _any_ new algorithm. If effort is
to be spent, it should be spent on the one with the greatest return for
that investment, and making sure those benefits are clear and articulable.
The signaling and interoperability layers of the PKI are much more rusted
(RFC 8701), and the solution for that is to focus on ensuring the necessary
agility is there (c.f. lifetimes, profiles for intermediates, more regular
root removal/replacement). In the near term, things like TLS delegated
credentials afford the server-side timing attack resistance and cheaper
handshaking, and thus represent reasonable steps for the ecosystem.

On Thu, Mar 26, 2020 at 5:19 PM Mehner, Carl <Carl.Mehner at usaa.com> wrote:

> (Sorry for top-posting … outlook isn’t great for mail forums).
> That quote was referring to Tim H saying that because we weren’t using
> Ed25519, the Web PKI was behind, you replied saying that it should be
> framed as a practical matter around cost [1].
> Based on the minutes you linked to, I can see how different conclusions
> can be reached on the best way forward 1) deploying a new SPKI now to find
> things that will break and need new libraries, or 2) waiting until the PQC
> algorithm decision is made before testing new cert types.
> In my mind, working on things that we agree are secure now (Ed25519) in
> order to sus out incompatibilities can help us when it is time to deploy
> PQC-certs in the future. I would argue that it is important to do this now
> because we do not know how long the PQC decision will take nor how long we
> have until PQC is an imminent threat requiring change. Given enough time,
> testing, and motivation, I think people can be ready for a PQC transition
> in server certificates. If the testing waits until PQC is needed, we won’t
> find issues until it’s too late. Changing to a new SPKI now helps us have a
> longer runway for testing new algorithms to help companies/people find what
> technologies will be affected by other non-optional algorithm changes in
> the future and begin working with their vendors and upgrade plans now
> rather than later.
>
> -carl
>
> [1] https://cabforum.org/pipermail/servercert-wg/2019-June/000875.html
>
> On 3/26/20, 11:25 AM, "Ryan Sleevi" <sleevi at google.com<mailto:
> sleevi at google.com>> wrote:
>
> On Thu, Mar 26, 2020 at 12:03 PM Mehner, Carl <Carl.Mehner at usaa.com
> <mailto:Carl.Mehner at usaa.com>> wrote:
> Hi Ryan,
>
> From: Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org<mailto:
> servercert-wg at cabforum.org>
> > It looks like you snipped some of the follow-up discussion that
> clarified this. Was that intentional?
>
> I recall you mentioned, “the benefits are significantly outweighed by the
> costs” but it appears that you neglected to say what those costs were. That
> said, there’s also a note about hashing this subject out in F2F meetings,
> so there may be more behind that than what’s available on this mailing list
> (I couldn’t find anything in meeting minutes either that seems to
> adequately address this).
>
> I'm not sure where that quote is being attributed to?  The specific
> discussion continued at
> https://cabforum.org/pipermail/servercert-wg/2018-December/000484.html<
> https://urldefense.com/v3/__https:/cabforum.org/pipermail/servercert-wg/2018-December/000484.html__;!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLJxo1--o$>
> , and shows why the framing that was proposed by Phillip (and endorsed by
> Kurt's reply) was problematic.
>
> In terms of F2F discussions, this was discussed pretty extensively at
> Meeting 39 -
> https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Non-FIPS-algorithms-for-customer-public-keys-and-certificate-signing
> <
> https://urldefense.com/v3/__https:/cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/*Non-FIPS-algorithms-for-customer-public-keys-and-certificate-signing__;Iw!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLt2mcLqs$>
> - and continued at Meeting 40 -
> https://cabforum.org/2017/03/22/2017-03-22-f2f-meeting-40-minutes/#Process-for-Adoption-of-Post-SHA-2-Algorithms
> <
> https://urldefense.com/v3/__https:/cabforum.org/2017/03/22/2017-03-22-f2f-meeting-40-minutes/*Process-for-Adoption-of-Post-SHA-2-Algorithms__;Iw!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLuybG6-k$
> >
>
> The IETF TLS WG discussed at length the challenges with SPKI algorithms,
> in the context of a much older algorithm - RSA-PSS - and the compatibility
> and interoperability problems that can be had. This is why the TLS 1.3
> design is what it is.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200326/c283a617/attachment-0001.html>