Re: [Cfrg] Actual security levels for IETF crypto

[Yoav Nir <[e-mail]>]

> On Oct 27, 2014, at 5:35 PM, Watson Ladd <[e-mail]> wrote:
> 
> On Mon, Oct 27, 2014 at 6:27 AM, Stephen Farrell
> <[e-mail]> wrote:
>> 
>> 
>> 
>> On 27/10/14 05:34, D. J. Bernstein wrote:
>>> CFRG's stated goal in the curve-selection process is to "provide real
>>> value" not just to TLS but "the IETF more widely". As an illustration of
>>> how crypto is in fact used in other IETF protocols, here are the three
>>> most common security levels chosen by top-level domains that use DNSSEC:
>>> 
>>>    ~80-bit security (1024-bit RSA): 286 TLDs.
>>>    ~90-bit security (1280-bit RSA): 192 TLDs.
>>>   ~110-bit security (2048-bit RSA):  22 TLDs.
>>> 
>>> The fastest-growing category is ~90-bit security (1280-bit RSA). I don't
>>> see how this fits the "marketing department needs powers of 2" theory. I
>>> do see how it fits the "users are choosing weak crypto for performance
>>> reasons" theory.
>> 
>> I don't think you can safely extrapolate from DNSSEC deployment
>> to "actual...IETF crypto." TLS is far far more widely deployed.
>> (Its fair to say that DNSSEC deployment is a bit sad, and to try
>> to make that better, but that's a different point.)
> 
> 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?

As the IETF or the IRTF all we can ever do is publish RFCs recommending this or that. What is deployed is not up to us. We’ve had three newer version of TLS since 1999, and there’s still a depressingly large amount of SSLv3 going on. We can recommend that people stop using 1024-bit RSA, but it’s only when auditors start failing audits when such certificates are present, and when CAs refuse to sign such certificates that they actually go away. The auditors and the CAs have some power. We don’t. So no, we don’t recommend 90-bit security for DNSSEC, but people deploy what they deploy. And since auditors and reporters don’t care about DNSSEC, using 90-bit security doesn’t get you any bad points anywhere.  And we have no control of that.

> Or that DNSSEC doesn't have the same
> "marketing issue" as TLS? Even if we look at TLS, performance matters
> a lot: it's the number 1 cited reason for not deploying TLS, and the
> stated reason we had this Curve25519 in TLS draft in the first place.

Performance matters. That is why AES-GCM is gaining popularity fast. But ECDHE is also becoming much more common, even with RSA certificates, and that is a net loss for a server over RSA keying.

> Furthermore, I'm sure if we crawled server certificates, we would see
> close to no E521 usage, either at the roots or intermediates, or
> leaves. The EFF SSL Observatory has the data: I would need to analyze
> it to see exactly what is going on.

Or you can see Mozilla’s telemetry:
http://telemetry.mozilla.org/#filter=release%2F32%2FSSL_AUTH_ECDSA_CURVE_FULL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph
5.12 G observations of P-256
8.48 K observations of P-384
135 observations of P-521

> We could easily achieve higher levels of security by expanding RSA
> keys, or using larger Diffie Hellman moduli. The only reason we don't
> is that performance matters, and bandwidth matters. And when you
> ignore these factors, you get DNSSEC, which has massive amplification
> issues and is nowhere near as secure as it could be if elliptic curve
> signatures had been used instead of RSA.
> 
> Sincerely,
> Watson Ladd