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

[Kristian Fiskerstrand]

On 04/02/2017 06:00 PM, Pete Stephenson wrote:
> 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.

Let me elaborate on this as it is indeed a fair comment. The argument
would be that, if RSA should not be used but ECC should for some reason,
we should rather switch to only use ECC and not do dual stack, the main
purpose would be not to duplicate key management task, so picking
between the two, using RSA is still more operable than ECC -- hence
preference for staying with RSA unless there are convincing arguments to
the contrary. The only argument I can think of offhand is performance on
embedded devices an implementations that potentially is less prone to
side-channel attacks, none of which I necessarily believe are strong
arguments in this particular case of TLS access to keyservers.

> 
> 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?

if this is a worry we could use 3072 bit rsa keys (many are already 4096
bits) and yes, part of the thinking is the quantum computer resistance
in that consideration.

But I'm really more curious to arguments to switching to ecc in general :)

> 
> Cheers!
> -Pete
> 


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Whatever you do in life, surround yourself with smart people who'll
argue with you."
John Wooden

signature.asc
Description: OpenPGP digital signature