Re: [Cfrg] Actual security levels for IETF crypto

[Benjamin Black <[e-mail]>]

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).


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


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

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

> >
> > "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.


b