Re: [Sks-devel] ECC HTTPS certs for HKPS

[Phil Pennock]

On 2017-04-02 at 18:07 +0200, Kristian Fiskerstrand wrote:
> But I'm really more curious to arguments to switching to ecc in general :)

My argument is to switch to being dual-stack RSA+ECC and confirming that
this can safely be done, and providing a single-stack keyserver to make
it easier to test what would happen in a world where RSA is disabled.

Algorithmic breaks could come at any time.  I'd be much happier without
one, but I also like to have contingency plans in place.

For SSH, I have RSA+NISTECC+Edwards keys and push the three as a group
to anywhere which takes them.  I can disable one and not suffer on most
services.  A couple of services which are RSA+DSA only will break if RSA
is the one to go, since DSA in SSH maxes out at 1024 bits so I don't use
it.

For TLS, the draft adding Edwards curve stuff is nearing RFC publication
(AIUI) so we're close to having Ed25519 in TLS.

I'd like to know that I could disable the first to break (eg, NIST ECC)
and still have the others work.  I could even temporarily disable all
RSA in the event of implementation vulnerability disclosure (again)
until I get a chance to patch the stack and then generate fresh keys.

The goal being to keep working and not cut things off suddenly but to
always have a Plan B.  The details of ECC vs CEILIDH vs Naccache–Stern
vs Purple Fairy Dust are irrelevant, it's "having a Plan B" that I care
about.

-Phil

signature.asc
Description: Digital signature