Re: [Cfrg] Actual security levels for IETF crypto

[Watson Ladd <[e-mail]>]

On Oct 28, 2014 3:06 PM, "Benjamin Black" <[e-mail]> wrote:
>
> On Tue, Oct 28, 2014 at 1:02 PM, Watson Ladd <[e-mail]>
wrote:
>>
>>
>> On Oct 28, 2014 12:10 PM, "Benjamin Black" <[e-mail]> wrote:
>> >
>> > There is a very long tail effect here. While many individuals might
express performance as a reason for not deploying TLS, sites which
represent the vast majority of HTTP and SMTP user traffic are few and
universally deploy TLS. The performance concerns for such major services
are more about cost reduction: faster curves means fewer servers to handle
a given request rate (where connection setup is the dominant consumer of
resources). There is no option to not deploy TLS because such services can
buy more servers but they can't buy more trust.
>>
>> What's good about spending extra money?
>
> You stated performance was the main concern slowing TLS deployment. That
is only true for small sites who represent a small fraction of TLS
connections. For large players, TLS is a given and performance is useful
for reducing COGS or improving latency (where latency again is interesting
because there is correlation between lower latency and more money).

I want every connection encrypted. To the extent that slow performance
driven by acceptability concerns interferes with this, that's a problem.
I'm already sad that the current best performer in eBATS,  literally
thousands of times faster then RSA of similar security levels,  has been
ruled out.

Performance of ECC is a major reason Cloudflare could turn on TLS for
everyone. If they were stuck with DHE and RSA, it wouldn't have happened.
Let's not limit the scope of discussion to websites taking money.

>
>>
>>
>> >
>> > The amplification problems of DNSSEC are not related to the choice of
cryptography. Regardless of signature algorithm, DNSSEC responses are
significantly larger than requests, making them attractive for
amplification attacks.
>>
>> This is unavoidable,  but RSA makes it worse.
>
> Glad we agree. It is unavoidable, not caused by algorithm choice.

It's made worse by algorithm choice, and some misfeatures like domain
suicide are directly caused by the barely adequate strength of RSA 1024,
and consequent workarounds.

>
>>
>> >
>> > DNSSEC did not use EC originally because 15+ years ago when it was
designed EC was still young and the patent situation made such a move
infeasible. RSA was prevalent, unencumbered, and implementations were fast.
EC was specified for DNSSEC only within the last 5 years, yesterday in DNS
deployment time, and for much of that time patent concerns persisted,
further retarding adoption.
>> >
>>
>> ECC was invented in 1986. Unlike RSA, the algorithm was not patented by
its inventors. All of the patents were on implementation techniques, and
none were required to implement. Picking RSA hasn't measurably speed DNSSEC
adoption.
>
> You are well aware the history of ECC for widespread industrial use
starts with SECG, which formed in 1998 and published SEC1 1.0 in 2000. RSA
was chosen at the time because it was the best available option. The speed
of adoption is unrelated to the algorithm choice in DNSSEC, except that
mandating ECC in 1999 (or 2004) would've precluded most deployment.
>
> Are you seriously now arguing that patents on implementation techniques
are no big deal and people should just work around them? I recall the
opposite position being vigorously argued in the recent past.

By me? Which patent would that have been? Actually I'm arguing that ECC
patent concerns were massively overblown, and that speed gains over RSA
were attainable even without taking advantage of the specialness of the
prime. But that's really far from the choice we face now.

>>
>> Furthermore,  if the cryptography was fast enough to apply to every
packet, the design would look considerably different. As a result of slow
signing, we got fast offline zone walking.
>
> No idea what point you're making. You seem to be simultaneously
suggesting that current DNSSEC key sizes are somehow relevant and that
DNSSEC itself is garbage, a case study in how not to do it, and would be
far better if only they'd applied knowledge from 15 years in the future.

No: I'm arguing that the choice of RSA signing had implications for the
design of DNSSEC that were negative,  in part because of RSA key sizes and
speed, and that users of DNSSEC are constrained by performance and other
problems rather then going for the most secure option. It's a case study in
slow crypto forcing bad design choices.

>>
>> >
>> > "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes."
>> >
>> > ECDSA, and with it P256, was not specified for DNSSEC until 2012, in
RFC6605. RFC4034, which updates the original DNSSEC specification, includes
an ECC code point for signatures, but does not offer anything more and this
code point was not used for either P256 or P384 based signatures.
>> >
>
> ...
>
>>
>> This is a reason for using the same single measurement framework for all
benchmarks. I could easily imagine a systematic 10% measurement error
caused by differing overheads when measuring the same code.
>>
>> I don't think the claims are false. I think it's hard to compare
measurements made different ways on different machines, which is why Mike
Hamburg email above is as good as it gets, and with relatively little
effort we could have much better data.
>>
>> But if we accept the numbers above, what does that say about NUMS vs.
Other? It looks to me that for minor changes in security level or
performance,  major gains in the other variable are possible.
>
> Trustworthiness of the curves are also a consideration, though obviously
one not as easily measured as performance. That it is hard to measure or
not a serious concern for you does not invalidate its importance to many.

In what way is 25519 less trustworthy them the Microsoft proposal?
Performance is also very demanding and imposes rigidity. How much
performance are you willing to give up for a little trust, which can't be
easily measured, and might point the other way in the case of E-521 with 3
independent discoveries?

Curve choice matters less then point format and signature issues where we
are also disappointingly far from agreement. Or maybe we are close enough
that no one bothered to respond beyond Andy Lutomirski because the answers
were obvious.

>
>
> b