Subject: [Cfrg] Actual security levels for IETF crypto

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Oct 2014 05:34:52 -0000

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.

---Dan

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Oct 2014 13:27:14 +0000

> do see how it fits the "users are choosing weak crypto for performance

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

S.

> 
> ---Dan
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
> 
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 27 Oct 2014 08:35:21 -0700

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

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.

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Yoav Nir <[email-masked]>
Date: Mon, 27 Oct 2014 18:03:19 +0200

> On Oct 27, 2014, at 5:35 PM, Watson Ladd <[email-masked]> wrote:
> 
> 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

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.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Oct 2014 00:36:01 +0000

On 27/10/14 15:35, Watson Ladd wrote:
> "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.

S.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 27 Oct 2014 18:24:50 -0700

> None of the above. I was saying (only) that that extrapolation

Huh? The point DJB and I are trying to make is that deployment of
crypto is frequently performance constrained, and that the marketing
benefits of the NUMS curves are completely overstated, as shown by the
fact that people don't deploy crypto because it has nice round
numbers, but because it meets the performance demands they have.

In particular, it's clear that people prefer P384 to P521 in TLS,
because of performance issues (or maybe compatibility). It's also
clear that RSA deployments in DNSSEC with very low security remain
popular, in part because of specific issues with DNSSEC that
essentially require RSA+SHA1 to be used for backwards compatibility,
and that end up capping the maximum security at that of RSA: these
reasons don't apply as strongly to TLS.

(Furthermore, OAEP was introduced a full 6 years before RFC 3110 was
written. Guess what RFC 3110 uses?)

If you think DNSSEC and the data we have on TLS certificates are both
wrong, go ahead and find a crypto deployment that you think actually
is representative, or explain that factors that make these irrelevant.
Just as if Microsoft thinks the numbers we are getting for their
curves are wrong, they should submit them to SUPERCOP. (hint hint).
But don't say that the real world, observed, behavior and choices of
users, are irrelevant to deciding what their preferences are.

Sincerely,
Watson Ladd

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 27 Oct 2014 21:43:42 -0700

On 10/27/2014 06:24 PM, Watson Ladd wrote:
> because of performance issues (or maybe compatibility).

Among these two, I think this is more due to Suite B and patents.

> It's also

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 01:28:52 -0400

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

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.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 27 Oct 2014 23:29:44 -0700

On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
> A more apt comparison might be to try to measure average human height from a
> sample of Formula One drivers.
>

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

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 09:02:55 +0200

I tend to agree with Watson. We’ve been trying to do this in a “waterfall” way, where first we define requirements, and then choose from among the proposals those that fit the requirements best.

But in fact the we don’t have firm requirements. We’re pretty much in agreement that we want two “strength” level of curves. But it’s not clear how strong.

For the “weaker” curve, we’re pretty much in agreement that we want 128-ish work factor. This is both because of security (NIST and cryptographers tell us that we need this much) and because at the start of this process we had a good candidate. I put the “weaker” in quotes because if we actually get 128 or even 112  bit work factor, then breaking this is beyond the power of any actor for the next 30 years. The weaker curve already has quite a bit of margin. We’ve had a 64-bit work factor collision attack on SHA-1 for several years now, and yet nobody has produced a pair of colliding buffers.[1]  For a 128-bit work factor, please insert platitude here about the size of the universe, silicon atoms, billions of years and the heat death of the universe.

But because the weaker curve is so strong, there’s no rational way to write requirements for the “stronger” curve. Again, the “stronger” is in quotes, because if something is impossible, talking about something being a billion times more impossible or a trillion times more impossible is silly. Attacks get better, but there’s little information about yet-undiscovered attacks, so we don’t know if the attacks we’ll have in 20 or 30 years will drop the work factor for the weaker curve from 128 to 112, or all the way down to 64. Similarly, there is no way to know if an attack that will make a 384-bit curve vulnerable will leave a 512-bit curve still secure enough.

IMO what we should be worried about is usability. We should assume that both the strong and weak curve will be implemented, but the weak curve will be overwhelmingly more common in use. In case the weak curve that we pick turns out to have a flaw, it should be possible for implementations to switch by mere configuration. And it should not mean that all hardware has to be replaced. So unlike PHB, I believe that we should be worried about performance or the stronger curve, because it’s going to serve as a backup. So yes, we do want a margin above ~128. ~192 or higher is a good choice. But I don’t believe that Goldilocks is “not high enough”. I think it is. And if we get an attack that brings that ~224 bit work factor down to something breakable, we probably need to re-think our use of ECC anyway.

Yoav

[1] I’m sure there are quite a few actors who can perform a 64-bit attack. It’s been 19 years since a university brute-forced a 56-bit DES key. I’m sure we have computers that can do 256 as much work. Point is, it’s not so easy.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 28 Oct 2014 08:56:13 +0000

> reasons don't apply as strongly to TLS.

I would like to offer that DNSSEC key size decisions are more based on herd mentality
i.e. "X does this way so I will copy” 
Secondly DNSSEC records are popular as DNS amplification attack vector thus
some people have keep their RSA key sizes small.

Thirdly there is also a rational process going on here, does my vanity domain need the 
same security level as say PayPal ? 
Of course once the world starts using ECC for DNSSEC peoples choices become more restricted, right 
now we see frequently that Key Signing Key is 2048 bits but the key that signs the zone data is 1024 
this is because updating KSK is hard but changing ZSK is easy. As an example this is what the root does, 
in that case the ZSK is changed every 3 months, limiting the time window it can be cracked. 

One of the worst possible inputs into deciding how to use keys in DNSSEC is the advice from NIST, 
there is nothing wrong with using short lived RSA 1024 bit key (3 to 12 months)  and using SHA1 in short lived signatures (less than 2 weeks). 
The NIST advice covers documents that need to be verified in 30-50 years which is totally different domain. 

	Olafur
PS: I’m working on rolling out DNSSEC for a large third party DNS Operator and we will use ECDSA P256 for the 1M+ domains we operate, 
and the reason has more to do with size of signatures than anything else.

---

From: Jakob Breier <[email-masked]>
Date: Tue, 28 Oct 2014 10:12:42 +0100

> written. Guess what RFC 3110 uses?)

You were probably thinking of the Probabilistic Signature Scheme? While 
I'm not sure it is a bad idea, a quick Google search did not come up 
with anyone using OAEP for signatures. Also, both papers were written by 
Bellare and Rogaway, so I guess they would have reused OAEP for 
signatures, if the proofs were feasible.

You can still make the same point by arguing that the PSS paper was 
published a full 5 years before RFC 3310 came out. On the other hand, 
adoption of PSS in cryptographic standards wasn't as fast as OAEP. The - 
then current - RFC 2313 (PKCS #1 v2.0) only takes note of its existence:

>     Editor's note. RSA Laboratories is investigating the possibility of
>     including a scheme based on the PSS encoding methods specified in
>     [3  <https://tools.ietf.org/html/rfc2437#ref-3>], which would be recommended for new applications.

And PKCS #1 v2.1 only came along in 2002 [1], a year after the 
publication of RFC 3110.

Regards,
Jakob

[1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Oct 2014 10:28:17 +0000

Hiya,

> numbers, but because it meets the performance demands they have.

Yes, and I'm neither agreeing with nor disagreeing with that
point. I am simply saying that it's fallacious to argue about
all "IETF crypto" solely based on a few hundred key pairs of
any sort. So while I don't have a dog in the "which curves" hunt,
I would not like to see even the correct conclusion reached based
on bad argument.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 08:32:20 -0400

> in the range of keys that do fit, people are not going to the maximum

Until some of the patents expired a few months ago, most people didn't
have any interest in ECC at all. The risk of a lawsuit was large, the
benefit
of ECC over RSA, questionable.

The market is split between two concerns. One is to have the absolute best
industry standard crypto, the other is to support 100% of the browsers in
use. What the certificate holders are interested in is converting shopping
carts into orders.

> to protect TLS.

They are? I hadn't noticed. I guess you are referring to ephemeral use,
which isn't really the same as signing static data like certs or a zone.
Adoption is much easier.

It also didn't happen to 384 bit curves in PKIX: no
> ludicrously oversized 16384 virtually unseen in comparison.

RSA imposes serious costs as the key size increases. Not least lack of
browser support.

I forget which browser is holding up 4096, I suspect its another Windows XP
thing. But the problem with RSA over 2048 is that the extra bits buy almost
nothing.

> What evidence do you have that this one-upsmanship actually happens in

Customer surveys and A/B testing on marketing.

> little harm in including it.

No, there is a lot of harm.

The real reason for going through this process is not because the existing
curves are bad, its because the deployment of ECC has stalled due to the
IPR FUD. Adopting a shiny new set of curves that everyone can agree on is
the way to restart the process. CAs who were laggards in the process get a
chance to catch up. Which means they don't need to continue to play boat
anchor.

Put two options on the table and there is a story that can sell ECC and we
can converge on one approach that has a pretty decent chance of getting
comprehensive support so that it is ready when 2048 starts to look soft and
we really need it.

Having 30+ curve choices harms deployment because that is a choice most
folk don't feel qualified to make. So they stick with RSA2048 till the
market decides. Which means the market doesn't make any choice at all.

Back when the Web was only one of 30 odd network hypertext systems, I went
after the Clinton Whitehouse to deploy the Web because I knew that was the
way to win the standards battle. The early microcomputer market had seen
dozens of machines appear then get replaced by newer, better models. Until
IBM appeared and legitimized the microcomputer with the IBM PC.

> However, given that there are 480 bit

The idea we can balance security and performance is nonsense. They are
incommensurate. Consider the following cases:

1) Curve 25519 is too much overhead.
2) Curve 25519 is acceptable but ~512 is not.
3) ~512 is acceptable.

For reasons discussed earlier, there will always be constrained devices for
which case 1 applies, but any device currently doing RSA2048 can do ~512
without any difficulty.

So the only area where a 'tradeoff' is even arguably an issue is case 2
which is a very small slice to start with and going to get thinner over
time because the growth in devices is at the ends of the performance curve,
8 bit devices and 64 bits.

We can't balance performance and security, so we give a binary choice. If
you can do ~512 then do it, otherwise there is the ~256 option.

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Oct 2014 22:04:18 +0900

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

s/500/512/  and i thought dnssec required edns0 long size.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 09:22:51 -0400

> s/500/512/  and i thought dnssec required edns0 long size.

DNSSEC requires EDNS0 but the 1500 byte Ethernet MTU still bites.

If you are trying to get messages through a broken middlebox, you are
likely to find messages truncated at 512 (or sometimes 500) bytes.

So I can understand why people might try to make DNSSEC work with RSA1024
even though I don't think they have much chance of success.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 15:26:01 +0200

> On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> The market is split between two concerns. One is to have the absolute best industry standard crypto, the other is to support 100% of the browsers in use. What the certificate holders are interested in is converting shopping carts into orders.

There’s also the concern that I don’t want to buy any more servers/bandwidth/accelerators than I have to.

>  
> The idea we can balance security and performance is nonsense. They are incommensurate. Consider the following cases:

Totally disagree.

> For reasons discussed earlier, there will always be constrained devices for which case 1 applies, but any device currently doing RSA2048 can do ~512 without any difficulty.

It’s not a question of what they can or cannot do. According to the Mozilla telemetry, 95% of HTTP connections (unfortunately this statistic is not split by SSL/non-SSL) transfer less than 200 KB of data. Pretty much regardless of which PK and symmetric algorithms you use, PK operations will dominate. So if you have a lot of connections like this (think web services and simple sites), the number of machines you need to buy, power and maintain is inversely proportional to the speed of the PK operation. 

> So the only area where a 'tradeoff' is even arguably an issue is case 2 which is a very small slice to start with and going to get thinner over time because the growth in devices is at the ends of the performance curve, 8 bit devices and 64 bits. 

Going from 25519 to P-521 has some costs. If (as you claim) it has some advantages, then there is a trade-off. You might say it’s not important because other costs dominate this one. But there is always a trade-off.

> We can't balance performance and security, so we give a binary choice. If you can do ~512 then do it, otherwise there is the ~256 option.

Why should I?  Are you claiming that P-256 or X25519 are insecure?  

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Oct 2014 06:40:53 -0700

> You were probably thinking of the Probabilistic Signature Scheme? While
I'm not sure it is a bad idea, a quick Google search did not come up with
anyone using OAEP for signatures. Also, both papers were written by Bellare
and Rogaway, so I guess they would have reused OAEP for signatures, if the
proofs were feasible.

I did indeed mean PSS. Do not use OAEP for signatures. Thanks for fixing
that.

Well, that's the problem: standardization lags behind knowledge
significantly. Of course, the actual state of PKCS 1.5 signatures is
nowhere near as bad as PKCS 1.5 encryption, so it's much less urgent.
>>    [3], which would be recommended for new applications.
>
>
publication of RFC 3110.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 09:41:19 -0400

On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir <[email-masked]> wrote:

> > The market is split between two concerns. One is to have the absolute
> best industry standard crypto, the other is to support 100% of the browsers
> in use. What the certificate holders are interested in is converting
> shopping carts into orders.
>
> There’s also the concern that I don’t want to buy any more
> servers/bandwidth/accelerators than I have to.
>
> >

I don't think you did actually. I am arguing that there is no nuanced
tradeoff because people will either take the performance pick or the
security pick.

If we are going to make the security pick we are going to consider these

> > 2) Curve 25519 is acceptable but ~512 is not.

If we are going to take the performance pick then we are going to ask the

> Why should I?  Are you claiming that P-256 or X25519 are insecure?

Either performance is an issue or it isn't. This isn't a smooth yield curve
with a series of tradeoffs. We have two picks:

1) ~256: High Security and High Performance
2) ~512: Beyond all reasonable doubt security at modest performance penalty

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 16:26:58 +0200

> On Oct 28, 2014, at 3:41 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
> >
> I don't think you did actually. I am arguing that there is no nuanced tradeoff because people will either take the performance pick or the security pick.

And I am arguing that it is nuanced.

> If we are going to make the security pick we are going to consider these cases:
>  
> If we are going to take the performance pick then we are going to ask the question you do:
>  

I don’t think these are two separate cases. Performance is always an issue, but if picking Curve25519 means that traffic recorded today will be decrypted in 10 years, then I will take the performance hit associated with using P-521 as part of the cost of doing business. If you tell me that breaking one is impossible, while breaking the other is a billion times more difficult than impossible, then I have to ask, “why should I?"

> Either performance is an issue or it isn't. This isn't a smooth yield curve with a series of tradeoffs. We have two picks:
> 

Is it really modest?  P-256 is 4 times as fast as P-521. We don’t have numbers for a 512-bit curve, but Goldilocks is just over 3 times slower than Curve25519, whereas P-521 is 23 times slower.

So is there an argument to use #2 that is strong enough to overcome the performance penalty argument?

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Oct 2014 18:06:19 +0200

> 2) ~512: Beyond all reasonable doubt security at modest performance penalty

The problem is, the performance goes like:

"Orange level" (~200 bits[1]) is about 3x the cost of "Yellow level" (~128 bits).
"Red level" (~256 bits) is about 6x the cost of "Yellow level" and 2x the cost
of "orange level".

Those aren't trivial cost differences.

I think that unless we have curve that beats NIST P-384 in speed (and is
at least ~192 bits[2]) NIST P-384 will retain most of its (not very widespread)
use.

Also, with certificates, there is difference in value. CA certificates are
much much more valuable for attacker than just about any end-site certificate
(and exceptionally high-value end-site certificates are rare too).

So very few certificates would even need "red level" security.

Sucky performance doesn't matter very much if signing is rare and verification
can be cached.

[1] One can get some extra bits above 192 with very small cost due to lack
of good primes near 2^384 but some a good bit above.

[2] Due to pracical factors, it seems one can get a good bit above 192-bit
level for it.

-Ilari

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 28 Oct 2014 10:18:14 -0700

> Is it really modest?  P-256 is 4 times as fast as P-521. We don’t have 
> numbers for a 512-bit curve, but Goldilocks is just over 3 times 
> slower than Curve25519, whereas P-521 is 23 times slower.
>
Actually, we do have numbers.  They aren't quite apples-to-apples 
because of point formats, point compression, hashing and different 
benchmarking suites, but they're close.  And of course, keep in mind 
that these aren't benchmarks of curves, but of implementations.

Curve25519 takes 194kcy for an ECDH on Sandy Bridge (SUPERCOP).  I'm 
using Sandy Bridge and ECDH because we have the most benchmarks on that 
combination.  Point compression built-in.

Microsoft's ed-256-mers takes 234kcy (Bos et al, published).

P256 takes 374kcy for an ECDH on Sandy Bridge (Gueron and Krasnov, 
published).

ed-384-mers takes 617kcy (Bos et al, published).

Ed448-Goldilocks takes 667kcy (SUPERCOP), just under 3.5x Curve25519.  
Point compression built-in.

ed-512-mers takes 1293kcy (Bos et al, published).

Granger and Scott posted an E-521 implementation and claimed much better 
performance than this, but their implementation is not constant-time and 
their numbers didn't account for TurboBoost. Samuel Neves measured it 
with TurboBoost disabled and got 1030kcy on Sandy Bridge.

I wrote an experimental constant-time implementation of E-521 using 
Goldilocks as a framework, and measured it at 803kcy on Haswell. This 
would probably be in the same neighborhood as that 1030kcy on Sandy 
Bridge (~15% IPC difference and no AVX2).  Point compression built-in.

Trevor Perrin clocked OpenSSL 1.0.2's NIST P-521 at 1714kcy on Haswell, 
which would probably be just under 2MCy on Sandy Bridge.

OpenSSL's NIST-P-384 implementation isn't optimized yet, so it's even 
slower than P-521 at 2.2M Haswell cycles (Trevor again).

Cheers,
-- Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 13:56:14 -0400

On Tue, Oct 28, 2014 at 1:18 PM, Mike Hamburg <[email-masked]> wrote:

>> numbers for a 512-bit curve, but Goldilocks is just over 3 times slower
>> than Curve25519, whereas P-521 is 23 times slower.
>>
> benchmarking suites, but they're close.  And of course, keep in mind that
> these aren't benchmarks of curves, but of implementations.
>
> Curve25519 takes 194kcy for an ECDH on Sandy Bridge (SUPERCOP).  I'm using
> Sandy Bridge and ECDH because we have the most benchmarks on that
> their numbers didn't account for TurboBoost. Samuel Neves measured it with
> TurboBoost disabled and got 1030kcy on Sandy Bridge.
>
> Goldilocks as a framework, and measured it at 803kcy on Haswell. This would
> probably be in the same neighborhood as that 1030kcy on Sandy Bridge (~15%
> IPC difference and no AVX2).  Point compression built-in.
>

For the sake of comparison, where do RSA1024 and RSA2048 fit in?

[Accepting that the public/private key advantage flips]

And lets not forget that the performance issues are different for client
and server.

First, lets take the constrained devices off the table. Anything that is
struggling with X25519 is not going to look at anything stronger. So that
leaves non constrained clients and high volume servers.

As far as the client goes, the baseline is the RSA2048 public key
operation. Anything that takes that number of cycles or less is going to be
OK. Its moot anyway as the client does not make the choice.

On the server side things are a little more complex. But either it is
crypto limited or limited by something else. All the curves are going to be
faster than RSA2048 because we get the asymmetric advantage for private key
operations but in the sort term at least, we might lose the crypto
accelerator board advantage.

So I can see a strong argument for ~256 on the server and something much
higher (i.e. ~512). I don't see a case for something that is neither one
nor the other.

---

From: Benjamin Black <[email-masked]>
Date: Tue, 28 Oct 2014 12:09:51 -0700

Pardon the formatting, I'm responding to several of Watson's posts at once:

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

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.

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

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.

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.

None of this is indicative of a bunch of protocol design clowns screwing up
crypto. These are reasonable, even unavoidable, trade-offs. Similar
constraints resulted in the persistence of RSA for TLS certificates even as
EC was rapidly adopted for key exchange. It is unclear to me what lessons
you are taking from this history and what point you are trying to make.

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

"Just as if Microsoft thinks the numbers we are getting for their curves
are wrong, they should submit them to SUPERCOP."

To which numbers are "we" referring? The performance numbers from the NUMS
papers have been independently validated with the ECCLib implementation,
which was the reason for releasing it. If you mean that you are running
different benchmarks and getting different numbers, well, certainly. I
would expect that to be the case for any implementation of any curve. I
would not, however, insinuate that the authors of any of these
implementations are making false claims regarding performance.

b

---

From: Benjamin Black <[email-masked]>
Date: Tue, 28 Oct 2014 12:22:45 -0700

On Tue, Oct 28, 2014 at 6:26 AM, Yoav Nir <[email-masked]> wrote:

> > For reasons discussed earlier, there will always be constrained devices
> for which case 1 applies, but any device currently doing RSA2048 can do
> ~512 without any difficulty.
>
> It’s not a question of what they can or cannot do. According to the
> Mozilla telemetry, 95% of HTTP connections (unfortunately this statistic is
> not split by SSL/non-SSL) transfer less than 200 KB of data. Pretty much
> regardless of which PK and symmetric algorithms you use, PK operations will
> dominate. So if you have a lot of connections like this (think web services
> and simple sites), the number of machines you need to buy, power and
> maintain is inversely proportional to the speed of the PK operation.
>
>
Much like discussion of TLS deployment, discussion of which aspects
dominate in resource consumption is heavily skewed. For certain large
online retail operations, the resource requirements on front end systems
for constructing pages were (are?) such that there was at least an order of
magnitude more CPU consumed rendering pages than what would be needed to
terminate the TLS connections. One might reasonably ask if the money is
evenly distributed across 100% of connections in the Mozilla telemetry.

While I also disagree with what I see as overly simplistic analysis of
curve strength preferences, I see it as no better to base decisions on
overly simplistic analyses of traffic data.

b

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Oct 2014 13:02:03 -0700

On Oct 28, 2014 12:10 PM, "Benjamin Black" <[email-masked]> 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?

This is unavoidable,  but RSA makes it worse.

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

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.

> None of this is indicative of a bunch of protocol design clowns screwing
up crypto. These are reasonable, even unavoidable, trade-offs. Similar
constraints resulted in the persistence of RSA for TLS certificates even as
EC was rapidly adopted for key exchange. It is unclear to me what lessons
you are taking from this history and what point you are trying to make.
>
> To which numbers are "we" referring? The performance numbers from the
NUMS papers have been independently validated with the ECCLib
implementation, which was the reason for releasing it. If you mean that you
are running different benchmarks and getting different numbers, well,
certainly. I would expect that to be the case for any implementation of any
curve. I would not, however, insinuate that the authors of any of these
implementations are making false claims regarding performance.

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 17:02:01 -0400

On Tue, Oct 28, 2014 at 4:02 PM, Watson Ladd <[email-masked]> wrote:

> >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.
>
No but a great big troll went and sat on the optimizations necessary to
make it practical effectively scaring people away for 20 years.

Criticizing folk for decisions made 20 years ago is ok, but you have to
take time to understand what the constraints were. ECC has only recently
become viable commercially.

RSA has been completely unencumbered since 2000. I would much rather solve
my customers performance concerns by selling them a $10K crypto accelerator
board than to risk them being hit with a lawsuit that will cost them $3
million just to defend, $20 million to settle and risk damages of $500
million if they lose.

And those are real figures from cases I have been involved in. Prior art
can avoid the $500 million damages but only if you get a judge who isn't a
complete jackass and you are still out the $3 million defense costs.

On the Web Mail cases the prior art I have is pretty much as good as it
gets. I can prove that I invented Web Mail because it was one of the test
applications I used to fix the HTTP protocol and discovered POST was
utterly broken. But the defendants still pay big money to settle.

Given the financial state of RIM, the chance that the patents end up being
bought by a troll for trolling was quite high.

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Oct 2014 06:05:37 +0900

> even though I don't think they have much chance of success.

i run a few cctlds with 2048 for a long time and have no reports of
problems.  this is not to say that all crows are black.

randy

---

From: Benjamin Black <[email-masked]>
Date: Tue, 28 Oct 2014 15:05:45 -0700

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

> This is unavoidable,  but RSA makes it worse.
Glad we agree. It is unavoidable, not caused by algorithm choice.

> none were required to implement. Picking RSA hasn't measurably speed DNSSEC
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.

> code point was not used for either P256 or P384 based signatures.
...

> 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

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Oct 2014 15:59:54 -0700

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

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

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

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

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.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Oct 2014 04:24:54 -0000

Benjamin Black writes:
> 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.

I'm a big fan of basing decisions upon facts, so let's try an example.
Would you claim that Amazon---obviously one of the world's most popular
web sites; right now Alexa says #7---uses TLS?

If I try https://www.amazon.com, Amazon's servers redirect my browser
to http://www.amazon.com. Similarly, if I try a search on Amazon and
then insert "https" into the URL, Amazon's servers redirect my browser
back to unencrypted HTTP.

Evidently Amazon has done all the work of setting up an HTTPS server
whose only function is to give me "secured" redirections---a meaningless
form of "security" when the redirections are to unprotected web pages.
There are of course the occasional Amazon order/credit-card pages using
TLS, but the big picture is that most Amazon traffic is unencrypted and
unauthenticated.

How do you explain Amazon redirecting HTTPS to HTTP, if not performance?
What do you think will do the best job of actually encrypting Amazon's
web pages: crypto that provides exceptional combinations of security and
speed, or crypto that provides powers of 2 to the marketing department?

As another example, I just tried https://www.msn.com with various free
browsers (routing connections through proxies in a few countries), and
in each case received the following error message:

   This page is not available right now
   We're working to restore it as soon as possible. Please check back soon.
   Click here to try this page again, or visit: http://www.msn.com

http://www.msn.com is working fine, and I don't see people complaining
on Twitter about MSN being down. What fraction of MSN traffic is HTTPS?

There are a huge number of popular sites that redirect HTTPS to HTTP, or
that allow manual HTTPS but advertise primarily HTTP, or that don't work
at all through HTTPS. The use of HTTPS is slowly growing but real
traffic measurements such as

   http://www.caida.org/data/passive/trace_stats/chicago-A/2014/?monitor=20140821-130000.UTC

show that HTTP remains dominant---quite the opposite of your claim. 
Performance isn't the only obstacle to HTTPS deployment but it's clearly
the primary obstacle in many cases, such as the HTTPS-redirect cases.

Again, CFRG's stated goal in the curve-selection process is to "provide
real value" not just to TLS but "the IETF more widely". The current
reality is that

     ~2^0 security is dominant in pretty much every IETF protocol;
    ~2^80 security remains surprisingly popular despite many warnings;
    ~2^90 security is the fastest-growing level for DNSSEC TLDs; and
   ~2^110 security is the fastest-growing level for HTTPS.

There's overwhelming evidence that these choices of security levels have
been pushed downwards by real cost constraints. If CFRG actually wants
to make a difference---especially for the quiet majority using 2^0
security---then it has to take these constraints into account.

State-of-the-art ECC provides much better speed/security tradeoffs than
RSA, and should drastically improve the situation. But it's clear that
these tradeoffs will be damaged if CFRG imposes superficial marketing
rules such as 2^2^k security levels.

---Dan

---

From: Benjamin Black <[email-masked]>
Date: Tue, 28 Oct 2014 23:49:26 -0700

> web sites; right now Alexa says #7---uses TLS?
I would claim that you sought out the only US site in the top 25 that
doesn't use TLS for every page. Every other US site in the global top 25 is
TLS. How can that be if performance concerns are stopping deployment?

> speed, or crypto that provides powers of 2 to the marketing department?
Amazon, unlike email and search providers, has not been subject to
significant public and commercial pressure to deploy HTTPS for all pages.
They may choose to invest the resources to do such a transition, they may
not. The question is not what would do the best job of encrypting their
pages, it is what would cause them to move resources from building new
features to converting to HTTPS. I suspect there could be zero performance
overhead and they still wouldn't move without a business reason.

> on Twitter about MSN being down. What fraction of MSN traffic is HTTPS?
Are you saying MSN isn't HTTPS today because of performance concerns or
that people often don't know or care if their traffic is encrypted?

> show that HTTP remains dominant---quite the opposite of your claim.

A one hour trace from one location showing bits/sec is not sufficient data
to make claims about growth or relative scale.

> the primary obstacle in many cases, such as the HTTPS-redirect cases.
On what do you base this claim? My direct experience in recently working to
move numerous, large sites to HTTPS-only is that performance issues are
raised mostly for capacity planning and not to block deployment. Instead,
people want to do the right thing for customers.

In other contexts in the recent past, I've seen people refuse to deploy TLS
because they don't want to pay for certificates, because they were put off
by the perceived complexity, even because they were concerned about
performance, but were either unable to articulate specifics or based their
opinion on incorrect data (for example, comparing performance of DHE to
unencrypted requests). None of those are overcome by offering a somewhat
faster PFS they don't understand anyway.

> security---then it has to take these constraints into account.
Where is this overwhelming evidence? A 15 year old protocol in a scenario
that makes upgrades glacially slow? A single US site in the Alexa global
top 25 that doesn't use HTTPS for all pages? An hour of traffic at a single
point? There has been a massive acceleration in HTTPS deployment in the
past 18 months and it has been driven by exactly one cause: Snowden. The
same cause will continue to drive most deployment, regardless of what CFRG
does and despite the cost.

Large operators aren't pushing for faster crypto because the current stuff
is too slow to deploy. They are doing it because they have _already_
deployed the crypto and want to reduce costs.

> rules such as 2^2^k security levels.
You're arguing it's Performance! Performance! Performance! then talking
about speed/security tradeoffs? RSA is plenty fast for key exchange and TLS
deployment is what it is. Giving people more security for similar
performance won't move the needle. Moving the needle on this is not
exciting. It involves sending lots of pull requests to open source projects
so they have sane TLS defaults, including ECDHE, and grinding away for
years getting TLS deployed on large services.

My trustworthiness comment was not related to security levels.

b

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 29 Oct 2014 11:36:36 +0000

On 29 October 2014 06:49:26 GMT+00:00, Benjamin Black <[email-masked]> wrote:

>>> sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS.
>> [djb]: …Amazon…
>I would claim that you sought out the only US site in the top 25 that doesn't use TLS for every page. Every other US site in the global top 25 is TLS. How can that be if performance concerns are stopping deployment?

Um, your claim is patently false. I can name one right off the top of my head: eBay.

We are nowhere near universal TLS. Three things typically hold back universal TLS deployment:

• Cost - CAs, especially with a myriad smaller sites

Thanks StartSSL for leading with this with free DV certs. Unfortunately they charge for multidomain, wildcards and worst of all, revocation - a security disaster in the wake of Heartbleed and they refused to make an exception, so, um, thanks for all the fish but that's less helpful than we'd probably like for universal TLS.

Thanks to the CAs working with Cloudflare, including Comodo, for doing even better and doing this with ECC.

Thanks to the DANE WG for showing a potential way forward to replace and/or augment DV certs from CAs - if it gets traction.

• Performance

Directly and clearly tied in with cost. Cloudflare's recent improvements would have been impractical without the performance afforded by ECC.

Performance is a very major, even primary, concern for CDNs - ask Rich Salz?

State-of-the-art ECC to enable TLS everywhere is what we're being asked for, and what is needed.

• Deployment of universal TLS

Thanks to ad networks, transclusion and embedding, and the mixed-content problem, the other big barrier to universal TLS adoption seems to be simply that it hasn't happened already! That probably explains MSN, if the ad networks don't support it.

And why wouldn't they? Well, the above two give the big reasons.

If we can lower the barrier to adoption, in any way, we probably should. Higher performance crypto lowers that barrier.

- --
/akr

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 07:05:37 -0700

> TLS. How can that be if performance concerns are stopping deployment?

Is this actually true? go.com isn't. craigslist.org isn't, imgur.com
isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't,
instagram.com isn't, and huffingtonpost.com isn't. That's nearly half
of the top 25.

Maybe this is because the secret police aren't interested in the news you read.

> so they have sane TLS defaults, including ECDHE, and grinding away for years
> getting TLS deployed on large services.
>

What was it related to? You've never explained in detail why the
choice of your curve at the 512 bitlevel is more trustworthy than
E-521, with three independent discoveries, or how consequential the
choices in Curve25519 are for trustworthiness. We've kept asking about
this, and the story comes down to a generation method that doesn't
look that different, except it started with powers of 2 instead of
primes with the maximum performance possible. Even if there is a loss
in "trustworthness", how substantial is it?

Furthermore, what do you think about point formats? Our work is not
limited to to picking a formula, and while arguing about this is
amusing, it isn't actually going anywhere: the chairs are going to
have to decide.

Sincerely,
Watson Ladd

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 09:10:39 -0700

On Wed, Oct 29, 2014 at 4:36 AM, Alyssa Rowan <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

My claim is that performance is clearly not stopping deployment for major
sites, so let's whip out the data and break down the entire top 25:

1. google.com - TLS
2. facebook.com - TLS
3. youtube.com - TLS
4. yahoo.com - TLS
5. baidu.com - NO TLS; China
6. wikipedia.org - TLS
7. amazon.com - only TLS for account & payments
8. twitter.com TLS
9. qq.com - NO TLS; China
10. taobao - NO TLS; China
11. google.co.in - TLS
12. live.com - TLS
13. linkedin.com - TLS
14. sina.com.cn - NO TLS; China
15. hao123.com - NO TLS; China
16. weibo.com - NO TLS; China
17. blogspot.com - TLS
18. yahoo.co.jp - NO TLS
19. tmall.com - NO TLS; China
20. yandex.ru - NO TLS
21. vk.com - TLS
22. ebay.com - only TLS for account & payments
23. google.de - TLS
24. bing.com - TLS
25. sohu.com - NO TLS; China

13 of the top 25 have TLS enabled for everything. Of the 12 that don't, 8
are in China, precluding their use of TLS in any meaningful way. That
leaves us with 4 sites in the top 25 that could but don't yet have TLS
enabled for everything: amazon.com, ebay.com, yahoo.co.jp, and yandex.ru.

Why might Amazon and eBay not bother with it? Performance could certainly
be a concern, but I doubt, based on direct experience, that is the case. As
I said in my previous email, the Snowden leaks did not blowback on them so
they haven't been presented with the business requirement faced by many
others who recently enabled TLS everywhere.

As Yahoo has already gone TLS for their main site, lack of TLS on their
Japanese site suggests either they haven't gotten to it yet or they don't
see a business requirement to do so. I have no insight into Yandex not
being TLS, but let's assume the reason is entirely performance of ECDHE and
if only they had faster curves they would enable TLS. That's a single site
in the top 25.

A majority of the top 25 already have TLS enabled. The number one reason
for sites in the top 25 not having TLS: they are in China. That covers 21
of the top 25. This data shows clearly that performance concerns are not
stopping the largest sites, who have the most to lose, from deploying TLS.

s/especially/only/

Large sites are not concerned by this. Their costs are much larger and
unrelated to TLS.

> • Performance
>
> Directly and clearly tied in with cost. Cloudflare's recent improvements
> would have been impractical without the performance afforded by ECC.
>
>
Enabling TLS and enabling PFS are not the same thing. Sites using RSA for
kx already see the sort of performance we are discussing, and without
clients taking a large performance hit. Clients are hit disproportionately
by (EC)DHE, which is a particular concern for mobile. Do the curves we are
discussing take the client resource consumption for ECDHE below RSA? If
not, they won't help with TLS deployment, even if they increase the number
of TLS sites that enable PFS.

> Performance is a very major, even primary, concern for CDNs - ask Rich
CDNs have long offered TLS services because their customers require them.
There is a cost associated with this, of course. As none of the curves we
are discussing offer better performance than not using TLS at all, I don't
see that overhead changing much.

> State-of-the-art ECC to enable TLS everywhere is what we're being asked
Enabling TLS and enabling PFS are not the same thing.

> Thanks to ad networks, transclusion and embedding, and the mixed-content
> problem, the other big barrier to universal TLS adoption seems to be simply
> that it hasn't happened already! That probably explains MSN, if the ad
> networks don't support it.
>
Not the right answer on MSN, but you have hit on the real cost of
conversion which is that you can't simply flip a switch to enable TLS and
roll out. You have to deal with all the dependencies, whether it is your
own content, CDNs, ad networks, partners, etc. None of which has anything
to do with performance.

> If we can lower the barrier to adoption, in any way, we probably should.
> Higher performance crypto lowers that barrier.
>
>
No doubt. However, if the goal is universal TLS, then simply making it
faster is useful but probably not the most efficient path to get there.

b

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 29 Oct 2014 16:17:41 +0000

> 13 of the top 25 have TLS enabled for everything. Of the 12 that don't, 8 are
> in China, precluding their use of TLS in any meaningful way. That leaves us
> with 4 sites in the top 25 that could but don't yet have TLS enabled for
> everything: amazon.com <http://amazon.com> , ebay.com <http://ebay.com> ,
> yahoo.co.jp <http://yahoo.co.jp> , and yandex.ru <http://yandex.ru> ……………..
> 
> I have no insight into Yandex not being TLS, but let's assume the reason is
> entirely performance of ECDHE and if only they had faster curves they would
> enable TLS. That's a single site in the top 25.

Yandex is in Russia. Russia used to have rather strict regulations regarding
crypto (not unlike China). Possibly it still does. I would not be surprised
if there are policies affecting how much or how little TLS Yandex is allowed
to do.

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 09:17:37 -0700

> instagram.com isn't, and huffingtonpost.com isn't. That's nearly half
Global: http://www.alexa.com/topsites

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 09:21:53 -0700

> Global: http://www.alexa.com/topsites

Ok, I did US top 25. What does that say for your argument? Also, we can fix
TLS 1.3 to be faster, and use ECDSA certificates.

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 09:35:55 -0700

It says even your cherrypicked data tells a similar story. More than half
the US top 25 are already TLS for everything. Doesn't sound like evidence
supporting the claim that performance is the main impediment to TLS
adoption. Faster is good, but let's not delude ourselves on the impact
faster will have.

On Wed, Oct 29, 2014 at 9:21 AM, Watson Ladd <[email-masked]> wrote:

> Ok, I did US top 25. What does that say for your argument? Also, we can
> fix TLS 1.3 to be faster, and use ECDSA certificates.
>
> >
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 09:42:25 -0700

If you think I cherrypicked, go look at all national top 25 lists, and show
the US is a laggard. Throwing out unsupported accusations of misconduct
isn't helping.

You still haven't explained the merits of your proposal over the
counterproposal, instead choosing to double down on the "performance
doesn't matter" argument in the face of significant evidence.

I saw the top 25 list on the Alexa site and didn't realize this was not the
global one. I then went down and looked at each site. Accidentally using
the wrong data set is not cherrypicking.

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 11:52:46 -0700

On Wed, Oct 29, 2014 at 9:42 AM, Watson Ladd <[email-masked]> wrote:

> > It says even your cherrypicked data tells a similar story. More than
> half the US top 25 are already TLS for everything. Doesn't sound like
> evidence supporting the claim that performance is the main impediment to
> TLS adoption. Faster is good, but let's not delude ourselves on the impact
> faster will have.
>
> If you think I cherrypicked, go look at all national top 25 lists, and
> show the US is a laggard. Throwing out unsupported accusations of
> misconduct isn't helping.
>
I said global top 25, you dug down to a specific country. The US is not a
laggard, it is just a typical subset. Any country is going to show a larger
non-TLS percentage in the top N than the global top N because you are
moving further into the tail. Over time, the minimum size at which we can
expect TLS deployment will continue to drop and the per-country top N stats
will look more like today's global top N.

The largest sites are also the most performance sensitive/conscious, yet
are significantly more likely than smaller sites to use TLS for everything.
Why? Site operators deploy TLS because they see business value in it,
whether that value is "This is the right thing for customers" or "We must
address government snooping concerns" or "I think people will trust us more
if they see the little green lock in the browser bar". Without business
value, it is hard to justify the resources required to enable TLS,
regardless of performance.

> doesn't matter" argument in the face of significant evidence.
I am not saying performance doesn't matter. I am saying:

1) There are other important considerations, as well.
2) There is little evidence supporting, and what I see contradicts, the
claim that performance concerns are the main impediment to TLS deployment.

Again, please provide this significant evidence which unambiguously shows
actual, as opposed to perceived, performance concerns impeding TLS
deployment today. Fast curves will change the actual performance, but they
won't change the TLS is slow perception and they won't show the business
value to drive deployment.

>  I saw the top 25 list on the Alexa site and didn't realize this was not
> the global one. I then went down and looked at each site. Accidentally
> using the wrong data set is not cherrypicking.
>
Sure.

b

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 12:13:12 -0700

That seems reasonable. However, it means that the percentage of data
encrypted with TLS is far below the percentage one would get from your
preferred methodology. I'm starting to think that looking at the percentage
of data encrypted is more useful then percentage of big sites encrypting as
a result.

What if those resources in administrator time and effort were zero?
Obviously ECDHE is one part of this: one needs to work on making the
handshake more efficient.

Part of the problem as I understand is that browser vendors have
historically treated TLS sans certificate worse then cleartext. My
potentially wrong idea was that this was being changed in http/2.

But we can't all race to be the last to fix things, or nothing will ever
get fixed.

How do those other considerations support the NUMS proposal? It's not
obvious they do. Furthermore, the argument is high performance is extremely
demanding on curves: there aren't that many choices involved, as shown by
the independent generation of the 521 bit curve.

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 12:33:45 -0700

On Wed, Oct 29, 2014 at 12:13 PM, Watson Ladd <[email-masked]> wrote:

> > I said global top 25, you dug down to a specific country. The US is not
> a laggard, it is just a typical subset. Any country is going to show a
> larger non-TLS percentage in the top N than the global top N because you
> are moving further into the tail. Over time, the minimum size at which we
> can expect TLS deployment will continue to drop and the per-country top N
> stats will look more like today's global top N.
>
Percentage of traffic via TLS is a useful adoption metric, but I don't
think it tells us much about what sites are or are not deploying TLS. As an
example on the extreme end of the spectrum, if you looked at Chinese
traffic you would see far less TLS for reasons entirely unrelated to
performance or cost.

> The problems here are:

1) the administration time and effort are not zero.
2) the administration costs are likely far less than the developer and
infrastructure costs.

For example, without TLS I needn't concern myself with secrets management.
I configure Apache to use TLS, and then I have to enter a password to
decrypt the private key whenever the daemon starts. Do I store it without a
password? Do I have to enter it manually? Do I have automation do it, in
which case where do I store the password? It's not that these problems
don't have solutions, it's that they create overhead.

On the actual costs for enabling TLS there are so many details to get
right. Ensuring every piece of content goes via TLS so there are no mixed
content warnings and all functionality is present can be quite involved.
And then, what if I am not running the latest code on my trusty F5 load
balancer so I can't use ECDHE? Do I skip PFS altogether? Take the
performance hit of DHE? Pay more license fees? Buy a new load balancer?

These are all real problems I have personally faced repeatedly in deploying
TLS and they represent, in my experience, the real impediments to
deployment.

> get fixed.
Resources are limited, so we should set our priorities based on data. The
data does show TLS adoption below where we all want it. It does not show
that to be caused by performance concerns.

> the independent generation of the 521 bit curve.
I've said repeatedly in public and private that I am committed to an open
and thorough process, regardless of the outcome. I've also said repeatedly
that we should be starting from requirements and then consider _generating_
curves to meet them, rather than limiting ourselves to the curves at hand
or trying to contort the requirements to match an existing favorite.

b

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Oct 2014 19:47:08 -0000

Yoav Nir writes:
> 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.
  [ ... ]
> So no, we don’t recommend 90-bit security for DNSSEC

I have bad news for you: IETF has always recommended, and continues to
recommend, security levels of 2^90 or lower for DNSSEC.

RFC 2541 (March 1999) stated that "larger keys are more secure" but
"slower" and more of a bandwidth problem. It recommended a "minimum
algorithm modulus size" of "704 bits". For comparison, my recollection
is that actual early-2000s DNSSEC software documentation used 768 bits.

RFC 4641 (September 2006) again pointed to performance costs ("sizes"
and "time"---"don't needlessly double your key sizes"). It recommended
"1024 bits for low-value domains, 1300 bits for medium-value domains,
and 2048 bits for high-value domains" for key-signing keys, and "about
100 bits" fewer for zone-signing keys.

RFC 6781 (December 2012, current) again points to performance and claims
that "most zones can safely use 1024-bit keys for at least the next ten
years". What's actually deployed today, as I mentioned before, is mostly
a mix of 1024-bit RSA and 1280-bit RSA for TLD zone-signing keys. (The
key-signing keys tend to be much larger, an interesting example of users
happily pumping up the security when the speed doesn't matter.)

I'm pointing to DNSSEC because its performance problems are particularly
clear, but there are many other IETF documents complaining about crypto
performance and suggesting many different security levels. The smaller
recommended levels, and the smaller deployed levels, have always ignored
clear earlier warnings in the cryptographic literature.

Security is job #1, and I think everyone agrees that CFRG shouldn't even
consider curves that don't improve upon the RSA-2048 security level. But
this doesn't mean that CFRG should blithely ignore the performance
constraints that have led to low security levels in IETF documents _and_
in real deployments. It's clear that paying attention to the "Powers of
2!" marketing department would seriously damage the tradeoffs available
between speed and security---and it's quite difficult to believe that
this is what the TLS WG wanted from CFRG.

Benjamin Black writes, regarding HTTPS:
> Why might Amazon and eBay not bother with it?

Amazon _did_ bother fully configuring HTTPS---and then configured
_redirections_ from HTTPS back to HTTP for the vast majority of its
web pages. For example,

   https://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X

redirects to

   http://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X

rather than simply providing the same data through HTTPS. The typical
URLs on that page are of course HTTP rather than HTTPS, so subsequent
clicks will be much cheaper for Amazon's servers, and since the active
redirection kills all security there's no real incentive for users to
start with HTTPS in the first place.

The cost consequences are clear. Amazon is making HTTPS URLs work not in
the easiest way, and of course not in a secure way, but in the way that
ends up being cheapest for Amazon's servers.

If you think that there's a plausible alternative reason for Amazon to
have set up these HTTPS-to-HTTP redirects, feel free to say what that
reason is. Similarly, if you don't think that dnssec-deployment.org
chose a 1024-bit zone-signing key for performance reasons, feel free to
present your alternative explanation.

> I've seen people refuse to deploy TLS because they don't want to pay
> for certificates, because they were put off by the perceived
> complexity,

So you think Amazon didn't pay for a certificate, or was put off by the
perceived complexity? Do you understand that https://www.amazon.com is
in fact talking HTTPS to the browser?

> youtube.com - TLS

YouTube is an obvious surveillance target (e.g., named as an NSA PRISM
partner) for essentially all of the reasons that it is a censorship
target (see http://en.wikipedia.org/wiki/Censorship_of_YouTube), and is
a subsidiary of Google, which has been pushing fairly hard for nuking
HTTP in favor of HTTPS. So one would certainly _expect_ a redirection
from http://www.youtube.com to https://www.youtube.com.

However, I just connected to http://www.youtube.com and was _not_
redirected to https://www.youtube.com. I also tried various subpages,
again finding no redirections to HTTPS.

In this case, unlike Amazon, HTTPS doesn't redirect back to HTTP. So
it's possible that most YouTube users are using HTTPS. But you haven't
provided any evidence for this. You seem to have a very strange notion
of "deploy TLS" where setting up a TLS server constitutes success, no
matter how little traffic is actually being encrypted---so obviously you
aren't seeing what the performance impact of full HTTPS would be.

> Are you saying MSN isn't HTTPS today because of performance concerns
> or that people often don't know or care if their traffic is encrypted?

There _is_ an https://www.msn.com. It successfully negotiates HTTPS with
my browser and sends a web page---namely an error message with a manual
redirect to HTTP.

Earlier you wrote "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."

Surely you can see that some explanation is required. Whether or not
you're counting MSN as part of "the vast majority of HTTP user traffic",
would you claim that MSN "deploys TLS"? How do you explain MSN going
through all the work to set up an HTTPS server but then having the
server produce this error message?

> A one hour trace from one location showing bits/sec is not sufficient
> data to make claims about growth or relative scale.

It's publicly verifiable data at a typical link, accompanied by similar
traces from many other time periods, and it's obviously enough to put
the ball in your court. Do you have _any_ publicly verifiable evidence
to support your picture of HTTPS dominating total web traffic?

---Dan

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 29 Oct 2014 19:48:20 +0000

>  I've also said repeatedly that we should be starting from requirements and
> then consider _generating_ curves to meet them, rather than limiting ourselves
> to the curves at hand or trying to contort the requirements to match an
> existing favorite.

Strongly +1

---

From: Benjamin Black <[email-masked]>
Date: Wed, 29 Oct 2014 13:46:21 -0700

> reason is.

Usability and discoverability. Amazon wants to ensure that, to the extent
possible, regardless of what users type into the browser to find a thing on
Amazon, they find that thing. This discoverability in turn maximizes
opportunities for purchases. Converting to have everything served over
HTTPS would be an involved process to ensure all content and all
dependencies are also HTTPS and that all features and scenarios work as
expected.

The additional infrastructure cost for HTTPS would be noise.

> in fact talking HTTPS to the browser?
As I said previously, Amazon has no compelling business reason to deploy
TLS for all pages, so they don't do it. It really is that simple. If that
changes, they will deploy it, regardless of the performance.

> again finding no redirections to HTTPS.
You were not redirected because you were not logged in. If you are logged
into Google, Youtube HTTP redirects to HTTPS.

https://support.google.com/youtube/answer/2985327?hl=en

> provided any evidence for this.

If they are logged in, they get HTTPS. I have no data on what percentage of
Youtube pages are served to logged in users. I would be pleasantly
surprised if Google shared that information.

You seem to have a very strange notion
> aren't seeing what the performance impact of full HTTPS would be.
That is not my definition, as explained above.

> server produce this error message?
I would not claim that MSN deploys TLS today. I would claim that its not
having TLS deployed today is not due to performance.

> to support your picture of HTTPS dominating total web traffic?
Your data does not support the claim that performance is the limiting
factor in TLS deployment. Please provide such data or stop making the claim.

b

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 29 Oct 2014 22:29:13 +0100

D. J. Bernstein <[email-masked]>:

> have set up these HTTPS-to-HTTP redirects, feel free to say what that

Obviously, www.amazon.com isn't simply a single server. There will be fewer
HTTP servers handling cleartext traffic (port 80) than servers handling
TLS-encrypted traffic (port 443). That's convenient even if you entirely
ignore the computational cost of handling TLS, simply because it makes
private-key management much easier.

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 Oct 2014 06:06:18 +0900

for an actual measurement of port use of broadband users, see page 31 of
http://www.iij.ad.jp/en/company/development/iir/pdf/iir_vol24_report_EN.pdf
note that iij is more enterprise than consumer.

randy

---

From: Benjamin Black <[email-masked]>
Date: Thu, 30 Oct 2014 14:23:45 -0700

Thanks, Randy. 200% YoY increase in port 443 attributed to Snowden leaks,
with anticipation of that trend continuing, matches my anecdotal evidence
and expectation.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Oct 2014 00:20:13 -0700

Those percentages actually seem rather low.  While the IIJ data show
roughly 5:1 ratio of 80 to 443, Firefox telemetry shows roughly 2:1.  So
substantially more HTTPS.

http://telemetry.mozilla.org/#filter=release%2F32%2FHTTP_TRANSACTION_IS_SSL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph

--Richard

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 Oct 2014 16:51:11 +0900

> roughly 5:1 ratio of 80 to 443, Firefox telemetry shows roughly 2:1.
> So substantially more HTTPS.

that would be cheering.  very different measurements, of course.  as cho
san said, we have elephants who file share and other biases.  and, of
course, sampling from a browser has its biases, a lot happens over http*
which is not in a browser.

but numbers are good.  and i sure am cheered by yours.

randy

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 31 Oct 2014 08:05:35 +0000

On 31/10/2014 07:51, Randy Bush wrote:
>> Those percentages actually seem rather low.  While the IIJ data
>> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows
>> roughly 2:1. So substantially more HTTPS.

Of course, what is needed is to get it to ≈100%.

I think we recognise that high-performance strong crypto is needed by
the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)

- -- 
/akr

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 Oct 2014 18:23:48 +0900

> the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)

agree.  but, as has been a bit overdiscussed, we would like the servers
and clients not to be biased against strength.  maybe this is naïve, but
one step in that direction is to get the performance numbers that have
been published in recent days and in supercop into <ugh> marketing form.
and then strongly encourage tls and dnssec to *default* to strong
crypto.  i would appreciate help trying to get ed25519 into bgpsec,
which is in draft.

randy

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Oct 2014 12:18:08 +0200

Well all of that TLS needs to check OCSP or CRLs, so we'll always get some HTTP, and there's captive portals. But if we can get real browser traffic to nearly all encrypted, then we've made some progress.

-----Original Message-----
From: "Alyssa Rowan" <[email-masked]>
Sent: ‎10/‎31/‎2014 10:05
To: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Actual security levels for IETF crypto

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Oct 2014 12:27:46 +0200

Marketing is interested in exactly two numbers: Session setup rate and concurrent session rate.

For the first we have to estimate how many cycles a TLS handshake takes in addition to the signature and ECDHE, then add that number to the numbers from supercop and divide the result into the cycles a 'typical' server can do in a second. Naively that's clock speed multiplied by core count, but in practice some cycles go to other things.

The second is more tricky because you have to define a profile for usage that mixes TLS handshakes with data traffic.

Come to think of it, there is an IETF group that deals with benchmarking methodology. Having a standard test and showing new algorithms getting better scores than current algorithms can go a long way. 

-----Original Message-----
From: "Randy Bush" <[email-masked]>
Sent: ‎10/‎31/‎2014 11:24
To: "Alyssa Rowan" <[email-masked]>
Cc: "IRTF CFRG" <[email-masked]>
Subject: Re: [Cfrg] Actual security levels for IETF crypto

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Oct 2014 09:19:52 -0400

> crypto.  i would appreciate help trying to get ed25519 into bgpsec,

I would much rather we have one algorithm/curve for ~256 and we use
that across all IETF crypto. If BGP is using something different from
TLS then there is a real chance that it does not get the attention it
should.

Which is a way of saying that I think the original premise of this
exercise is bogus. We are not really choosing algorithms for TLS
alone, whatever we choose is going to be the defacto industry standard
for everything. The only choice we have is whether to recognize that
or not.

Which in my view argues for ed25518 as the 'performance' curve. I
think I am correct in saying that DJB has picked up more actual use of
his curve than exists for any of the NIST curves in TLS.

I don't think there is a solid argument for NUMS256 over ed25519. If
people care so much about the additional rigidity of one extra bit
then they are not going to be using ~256 anyway.

The only strong reasons for going to ECC over RSA2048 are better
performance and shorter keys/signatures. And only the performance
reason is a really good one because DSA would give the short
signatures. The security improvement is real but not the reason to
change.

So at ~256 I see two factors that should drive the decision,
performance and backwards compatibility. Insecurity being a
disqualification factor rather than a distinguishing factor.

Which is a way of saying that maybe what we should do is to split the
process and decide on the performance curve first and then decide on
the ultra-confidence curve as a separate matter.

I think we could probably come to a decision on the performance curve
pretty quickly because it can be reduced to a set of disqualification
factors and one ranking factor.

The ultra-curve worries me because people keep proposing that we have
two ranking factors and attempt a tradeoff. Which is nonsense when we
don't know what the security differences really mean or what the
impact of the performance differences are.

The reason I want an ultra curve is simple, I need to have one
algorithm that is beyond question so that I can use it to establish
ground truths. Performance does not matter very much to me because I
don't expect to be using it in latency sensitive situations except for
validating proof chains. Since that is almost exclusively a client
operation and clients rarely have to check more than one at once, it
is not a major concern.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Oct 2014 07:05:00 -0700

> the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)

The idea that whiz-bang new crypto is the main barrier to 100% HTTPS
adoption seems rather naïve.  It helps, but there are several other, higher
barriers, like having to manage certs.  Or upgrade gear that only supports
SSLv3.

https://istlsfastyet.com/
http://poodle.io

>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A
> JBrM4k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE
> BKHuS2XQvgVHkq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t
> 4jPVVOVc7tXlV7ynbw7Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de
> FdfNqzTdB/fUtfWaOUHHN+GpsoadEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL
> Jri/SlYmdTfN77mxlyzICy94g6ebFnAXqG9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+
> kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09NMauyqpkWkSKx9e2BfMuhcwt
> NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKnVQ2wPLoxVM5o2voHE
> ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7IIbKmYBRTsq
> BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0S4K
> JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW
> Ekxep7A73BpE0IZrOKfc
> =UAgK
> -----END PGP SIGNATURE-----
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Oct 2014 14:10:56 +0000

On 31/10/14 14:05, Richard Barnes wrote:
> adoption seems rather naïve.  It helps,

I agree. Of course, having CFRG decide on precisely
which whiz-bang new crypto would be a good next step:-)

S.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 07:14:19 -0700

> which whiz-bang new crypto would be a good next step:-)

But our choices are not the fastest ones! We've decided to have genus
1 prime, no CM, which is a very conservative choice, but not
necessarily the fastest.

Anyway, since Benjamin Black has said he doesn't actually think we
should pick NUMS, but do our own picking, I think the answer is
clear...

---

From: Benjamin Black <[email-masked]>
Date: Fri, 31 Oct 2014 07:31:41 -0700

Watson,

Where exactly did I say "don't pick NUMS"?

b

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 07:35:37 -0700

> Where exactly did I say "don't pick NUMS"?

On October 29
"I've also said repeatedly that we should be starting from
requirements and then consider _generating_ curves to meet them,
rather than limiting ourselves to the curves at hand or trying to
contort the requirements to match an existing favorite."

That seems to suggest that we don't pick any curves, but instead
generate new ones.

---

From: Benjamin Black <[email-masked]>
Date: Fri, 31 Oct 2014 07:36:56 -0700

> the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)
Implicit in this argument is that TLS doesn't already have crypto with
sufficient performance and strength and that a meaningful percentage of
sites will refuse to move to TLS until a certain performance threshold is
achieved. I have seen no data supporting these claims.

I want faster crypto, too, to reduce costs and shave milliseconds. In the
mean time, I'm moving sites to HTTPS as fast as I can.

b

---

From: Benjamin Black <[email-masked]>
Date: Fri, 31 Oct 2014 07:39:30 -0700

Right, I didn't say don't pick NUMS. I said I believe the process should've
gone a direction it did not, which would've rejected _ALL_ current
candidates in favor of CFRG generating new ones. That is no more my saying
"don't pick NUMS" than your saying you want genus 2 on the table is the
same as your saying "don't pick Curve25519".

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 07:43:05 -0700

On Fri, Oct 31, 2014 at 7:39 AM, Benjamin Black <[email-masked]> wrote:
> "don't pick NUMS" than your saying you want genus 2 on the table is the same
> as your saying "don't pick Curve25519".

The unimportant question is why would we reject candidates for existing?

The important question is:
What's the case for NUMS vs. the other curves? Or do I have to go
write this email myself?

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 31 Oct 2014 14:56:09 +0000

>The unimportant question is why would we reject candidates for existing?

IF we were to reject the existing candidates - the reason for that would
be group’s desire to come up with *verifiably random-generated* curves so
that Nothing-Up-My-Sleeve argument would hold.

I personally am in favor of randomly generated curves, because I think
that performance penalty they are likely to incur would be justified by
public confidence in their security.

It is more difficult to prove that you did not “cook” your curve if it is
generated in other ways.

>What's the case for NUMS vs. the other curves? Or do I have to go

:-)

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 31 Oct 2014 17:14:35 +0000

Watson,

>1 prime, no CM, which is a very conservative choice, but not

I believe that a conservative approach is merited, given the potential
impact of getting it wrong. I don't think the world is ready for anything
too bleeding-edge right now - in which category I include genus 2 curves.

Thanks

Kenny