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

[Pete Stephenson]

On Sun, Apr 2, 2017 at 12:44 PM, Kristian Fiskerstrand
<address@hidden> wrote:
> On 04/02/2017 07:07 AM, Phil Pennock wrote:
>> We need to know it won't break clients.  So, setting up a keyserver
>> where dual-stack is present and asking people to point clients at it,
>> should help.
>
> In addition to not actually breaking clients, it'd be useful with some
> indication that added complexity has any value at all. In most cases ECC
> is lower security margin for lower interoperability. I'm still not
> convinced we have anything to gain by doing any dual-stack approach that
> also includes an increased workload to manage the certs.

Out of curiosity, how would it be less interoperable? The whole point
of having the server choose is so that clients that support ECC would
get ECC certs, while those that don't would get RSA certs. Servers
aren't going to send an ECC cert to a client that doesn't advertise
ECC support.

I was curious about what key exchange mechanism (e.g. DHE, ECDHE, etc.
-- my server only supports ephemeral key exchange) and protocols (TLS
1.0, 1.1, or 1.2) were being used by clients, so I have Apache keep
logs for a rolling 30-day window. If those logs would be of interest
to anyone (Phil?), I'd be happy to send suitably-anonymized (no IPs or
search queries) logs. In short, it appears that the vast majority of
client support ECDHE and prefer its use over DHE.

Also, what do you mean by "lower security margin"? 2048-bit RSA keys
are equivalent to an ~80 bit symmetric cipher. A 256-bit ECC key is
equivalent to a 128-bit symmetric cipher. Sure, RSA keys, due to their
greater length, will succumb to quantum computers later than the
shorter ECC keys, but is that a plausible threat at the moment?

Cheers!
-Pete

-- 
Pete Stephenson