Re: [Cfrg] Actual security levels for IETF crypto

[Watson Ladd <[e-mail]>]

On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker
<[e-mail]> wrote:
>
> On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell <[e-mail]>
> wrote:
>>
>>
>>
>> On 27/10/14 15:35, Watson Ladd wrote:
>> > Are you saying that DNSSEC isn't an IETF protocol? Or that we should
>> > only look at widely deployed protocols when determining how choices
>> > about what to deploy are made? Or that DNSSEC doesn't have the same
>> > "marketing issue" as TLS?
>>
>> None of the above. I was saying (only) that that extrapolation
>> is dodgy.
>>
>> If I measured a bunch of Dutch folks' heights, and assumed that
>> the average of those told me something about the average height
>> of a human I'd be making the same extrapolation mistake.
>
>
> A more apt comparison might be to try to measure average human height from a
> sample of Formula One drivers.
>
> There is a good reason folk choose a small key for DNS related work, the
> original protocol was limited to 500 bytes and quite a few bits of the
> Internet are still limited by the ancient ethernet MTU which isn't much
> bigger.

NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 bytes
in fact). DNSSEC failed to select small keys with adequate security,
and instead selected medium size keys with poor security, for reasons
that are now irrelevant, and were probably bogus even then. But even
in the range of keys that do fit, people are not going to the maximum
possible security.

>
>
> Funny that someone would present this particular argument then accuse others
> of 'marketing' as if it was a bad thing.
>
> My actual argument was that the market is subject to a one-upmanship effect
> that tends to drive key sizes upwards. So if there is 384 and 512 on offer
> with the new curves, don't expect anyone to use 384.

But this didn't happen to 256 bit curves, which are still widely used
to protect TLS. It also didn't happen to 384 bit curves in PKIX: no
one is moving to 521 bit curves, in part because of compatibility
issues,  but also because of lack of demand.  It also hasn't happened
to RSA key sizes: the most popular key size on the web from Mozilla
telemetry is 2048 bits, with 4096 the next most popular, and the
ludicrously oversized 16384 virtually unseen in comparison.

It also hasn't happened to root certificates: Based on a cursory look
(because clicking through every CA preloaded on my Mac was too much) I
would say there are between 30-35 RSA 4096 certificates, compared to a
vast number of 2048 and 1024 bit certificates. (My favorite is the
MD2, 1024 bit RSA, root certificate)

Looking at Mozilla's list of included CAs tells a similar story: the
spreadsheet is avalible at
https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&amp;single=true&amp;gid=1&amp;output=html,
and shows limited effect of one-upmanship.

In fact, the removal of 1024 bit root keys broke a fair number of
websites, and was only completed in 2013.

We also have data from Internet-wide scans of servers.
http://cryptome.org/2013/11/ecc-practice.pdf for ECC. The most common
key size is 256, followed by 384, and lastly is 521. Sadly similar
breakdowns by keysize for a similar scan aimed at RSA and DSA host
keys does not appear to exist. I would be surprised if it actually
supported the hypothesis.

What evidence do you have that this one-upsmanship actually happens in
selecting key sizes?

Furthermore, even if a 384 bit options sees limited use, there is
little harm in including it. However, given that there are 480 bit
options offering better performance, why not pick those instead?
Similarly, if 512 bits would make you happy, why not an even faster
521 bit option? And why deny users who want a 384 bit option for
performance reasons the option to have a more satisfactory for them
balance between paranoia and practicality?

Sincerely,
Watson Ladd