Subject: [DNSOP] Whiskey Tango Foxtrot on key lengths...

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Mar 2014 06:56:05 -0700

Bits are not precious:  Until a DNS reply hits the fragmentation limit of ~1500B, size-matters-not (tm, Yoda Inc).  

So why are both root and com and org and, well, just about everyone else using 1024b keys for the actual signing?

The biggest blobs of typical DNSSEC data are NSEC3 responses, and upping the key size to 2048b everywhere will not cause widespread fragmentation issues (4096b will... but only on those NSEC3 blobbies which require three RRSIGs, you can get non-NSEC3 responses to fit under that limit in most cases as those require only one or perhaps two RRSIGs)

1024B is unquestionably too weak, 768-bit RSA has been factored in 2010 as a low resource academic project:
http://eprint.iacr.org/2010/006.pdf

and 1024B is estimated at only "a thousand times harder".

RSA 768 took just 1,500 CPU-years on the fully parallelizeable sieving step, and 4 days of total time (but only 12 hours of successful computation) on a couple of ~35 node clusters.

And, frankly speaking, a 3500 node cluster for a day is $75K thanks to EC2.

Do you really want someone like me to try to get an EC2 academic grant for the cluster and a big slashdot/boingboing crowd for the sieving to factor the root ZSK?

So why the hell do the real operators of DNSSEC that matters, notably com and ., use 1024b RSA keys?

And don't give me that key-roll BS: Give me an out of date key for . and a MitM position, and I can basically create a false world for many DNSSEC-validating devices by also providing bogus time data with a MitM on NTP...

IMO, it is time for DNSSEC software to refuse to generate new RSA keys less than 2048b in length, and for the TLD and root operators to ditch short keys into the trash heap of history.  Well, the time was actually a decade ago, but hey...

If people actually want DNSSEC to be taken seriously as a PKI-type resource (a'la DANE), the DNS community needs to actually, well, use secure crypto.  1024b RSA is not secure.  Go Big or Go Home.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Mar 2014 06:57:17 -0700

> Do you really want someone like me to try to get an EC2 academic grant for the cluster and a big slashdot/boingboing crowd for the sieving to factor the root ZSK?

Crud, blew my math.  You'd want a 35000 node cluster, but thats still <$1M...  The point stands, 1024b RSA is unsafe.

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Mar 2014 23:22:42 +0900

> So why are both root and com and org and, well, just about everyone else using 1024b keys for the actual signing?

Those requirements (for the root zone keys) came from NTIA via NIST:

http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.pdf (9)(a)(i)

(well, NIST specified a minimum key size, but the implication at the time was that that was a safe minimum).

Bear in mind, I guess, that these keys have a publication lifetime that is relatively short. The window in which a factoring attack has an opportunity to find a result that can be exploited as a compromise is fairly narrow.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Mar 2014 07:52:24 -0700

> and 1024B is estimated at only "a thousand times harder".

Does that estimate include a prediction that the method to factor RSA will improve significantly as it has in the past? The authors were unclear on that in their estimate.

> Do you really want someone like me to try to get an EC2 academic grant for the cluster and a big slashdot/boingboing crowd for the sieving to factor the root ZSK?

Yes. If doing it for the DNS root key is too politically challenging, maybe do it for one of the 1024-bit trust anchors in the browser root pile. Failing that, just do it for any 1024-bit key. Successes in the past for the RSA challenge have gotten movement to happen.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Mar 2014 10:58:49 -0400

The NIST Guidance is from 2009. It is long since obsolete.

This is one of the reasons why we need to take advice on crypto algorithms
in house and make them IETF wide. Which is why I was asked to write this:

https://datatracker.ietf.org/doc/draft-hallambaker-consensuscrypto/

Having DNSSEC use 1024 bit RSA when we know it is unsafe sends a really bad
message. We are currently phasing out use of 1024 bit crypto in the Web PKI
for far less core concerns than the DNS roots.

This is one of the reasons why I am proposing support for multi-packet UDP
responses in PRIVATE-DNS. I am not sure that they are necessary. It might
well be that 1500 bytes is sufficient for all DNS messages as argued here.
But right now we have people making really bad decisions because of a
design constraint.

If we are going to encrypt messages that is going to eat up a few bytes in
each packet no matter what we do. IPSEC consumes quite a few bytes.

Trying to dance round this constraint is not making the protocol any
simpler. All it is doing is pushing the complexity balloon down in one
place and have bits pop out all over the place.

On Thu, Mar 27, 2014 at 10:22 AM, Joe Abley <[email-masked]> wrote:

> > Bits are not precious:  Until a DNS reply hits the fragmentation limit
> of ~1500B, size-matters-not (tm, Yoda Inc).
> >
> http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.pdf(9)(a)(i)
>
> Bear in mind, I guess, that these keys have a publication lifetime that is
> relatively short. The window in which a factoring attack has an opportunity
> to find a result that can be exploited as a compromise is fairly narrow.
>
>
> Joe
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

-- 
Website: http://hallambaker.com/

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Mar 2014 08:05:31 -0700

> (well, NIST specified a minimum key size, but the implication at the time was that that was a safe minimum).

Obligatory Snarky Note: these being the same people who, after 2007, said that, although you can create your own constants, you MUST still use the specified magic constants for Dual_EC_DRBG if you wanted certification, even though it was shown that whoever generated the magic constants could have placed a backdoor in them...

But seriously: it was clear back a decade ago that 1024b RSA should be depricated in 2010:

(current)
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

(historical)
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf

1024b RSA is really considered by NIST as only ~80 bits symmetric strength equivalent.

> Bear in mind, I guess, that these keys have a publication lifetime that is relatively short. The window in which a factoring attack has an opportunity to find a result that can be exploited as a co…

Except that if I'm in a position to actually use an old-factored root key, I'm probably also in a position to F-up your NTP.  How many computers complain bloody murder if the NTP server says "oh, you're clock is wrong by 20 days (or 200 days), here you go"?  And even if they do, how many users understand what that would mean?

And "relatively short" is still two weeks.  That is well within range of a nation-state adversary willing to build a custom sieving machine.  Look at how much SHA256 power has been generated with a well under $50M aggregate spending: its 35 PHash/s!  

We do want DNSSEC to work in the face of a nation state adversary, no?  Do you want to bet that the NSA has not already built a 1024b RSA factoring machine?

Likewise, we do want the ability to do historical things, no?  E.g. DNSSEC signature at time T to attest to a fact, using the captured DNSSEC validation chain at the time?

Frankly speaking, since the root uses NSEC rather than NSEC3, IMO it should be 4096b for both the KSK and ZSK.  But I'd be happy with 2048b.  Using 1024b is a recipe to ensure that DNSSEC is not taken seriously.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Mar 2014 11:05:59 -0400

On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman <[email-masked]>wrote:

> Does that estimate include a prediction that the method to factor RSA will
> improve significantly as it has in the past? The authors were unclear on
> that in their estimate.
>
> > Do you really want someone like me to try to get an EC2 academic grant
> for the cluster and a big slashdot/boingboing crowd for the sieving to
> factor the root ZSK?
>
> Yes. If doing it for the DNS root key is too politically challenging,
> maybe do it for one of the 1024-bit trust anchors in the browser root pile.
> Failing that, just do it for any 1024-bit key. Successes in the past for
> the RSA challenge have gotten movement to happen.
>

RSA-768 was factored just after that NIST guidance was published.

Based on previous history I expect RSA896 to be factored in the near
future. In fact it might have been factored already if all the worlds spare
CPU cycles were doing something more useful than mining bitcoin. So relying
on 1024 bit RSA is really leaving no margin for error.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Mar 2014 11:10:37 -0400

On Thu, Mar 27, 2014 at 11:05 AM, Nicholas Weaver <[email-masked]
> wrote:

>
> Frankly speaking, since the root uses NSEC rather than NSEC3, IMO it
> should be 4096b for both the KSK and ZSK.  But I'd be happy with 2048b.
>  Using 1024b is a recipe to ensure that DNSSEC is not taken seriously.
>
>
I think I know how to get this fixed.

I'll just tell the New York Times that DNSSEC has to be still considered a
science project until they stop relying on obsolete crypto.

---

From: "Rose, Scott" <[email-masked]>
Date: Thu, 27 Mar 2014 15:17:04 +0000

> (well, NIST specified a minimum key size, but the implication at the time was that that was a safe minimum).
Safe enough, but not preferred - it was due to practical concerns at the time.  It was set that low (lower than approved for general USG use) mainly because there were unknown devices that had issues with large packet sizes (i.e. keyroll being a problem with low PTMU settings).  There are still some issues out there but getting better. 

It is likely safe enough now to increase to 2048 for both KSK and ZSK.  Zones are doing this now and haven't seen any horror stories.

Scott

> Bear in mind, I guess, that these keys have a publication lifetime that is relatively short. The window in which a factoring attack has an opportunity to find a result that can be exploited as a co…

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 27 Mar 2014 16:51:14 +0100

On Thu, Mar 27, 2014 at 03:17:04PM +0000,
 Rose, Scott <[email-masked]> wrote 
 a message of 45 lines which said:

> It is likely safe enough now to increase to 2048 for both KSK and
> ZSK.  Zones are doing this now and haven't seen any horror stories.

If you want to test, rd.nic.fr has large KSK and ZSK (not because we
believe it is necessary for security but because we wanted to explore
the limits).

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 27 Mar 2014 18:14:31 +0100

* Nicholas Weaver [2014-03-27 14:56]:
> So why are both root and com and org and, well, just about
> everyone else using 1024b keys for the actual signing?

Here's a small statistic about RSA key lengths of 741,552 signed
second-level domains (collected on 2014-01-27, counting KSK and ZSKs):

> 1024 bit: 1298238 2048 bit:  698232 1280 bit:   28441 4096 bit: 
> 25326 512 bit:    8893 1536 bit:     385

Plus ~700 odd-sized RSA keys and ~250 DSA/GOST/ECDSA keys.

A domain owner of one of the 512-bit keys told me, it was the default
config in the signing tool he had used.

Regards,
Matt

- -- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 27 Mar 2014 14:18:37 -0400

On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman <[email-masked]> wrote:
> Yes. If doing it for the DNS root key is too politically challenging, maybe do it for one of the 1024-bit trust anchors in the browser root pile.

why would this be politically sensitive?

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Mar 2014 11:39:33 -0700

> why would this be politically sensitive?

Because the browsers have already decided killing of 1024b CAs is a good idea, and they could revoke just those CAs once someone breaks a 1024b example, since the browser vendors have good experience in revoking bad CAs already (queue DigiNotar...)

In contrast, DNSSEC seems mired in a 1024b swamp at the root, and when you can use an old key (which you can for the root, since you can fake everything up below that dynamically and fake NTP so that your bad key is still kosher), breaking a root key really would be breaking DNSSEC.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 27 Mar 2014 15:26:17 -0400

> In contrast, DNSSEC seems mired in a 1024b swamp at the root, and when you can use an old key (which you can for the root, since you can fake everything up below that dynamically and fake NTP so th…

that didn't answer the question really? Do you mean: "NTIA/ICANN (pick
your place depending on day and worldview) would be upset that someone
proved there are no pants on the emperor."

I'm not sure that matters though? Just because you did it and
published the result/example doesn't mean that this isn't already
happening all over the net, right? I don't know that there's a reason
to NOT do the experiment and publish, without some impetus, what's
going to drive the change? given other priorities that exist and
already have leadership attention...

Why don't you just go do the experiment nick and let us know how it goes?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Mar 2014 15:35:57 -0400 (EDT)

> Because the browsers have already decided killing of 1024b CAs is a good idea, and they could revoke just those CAs once someone breaks a 1024b example, since the browser vendors have good experien…

10-20 year validity.

> In contrast, DNSSEC

1 month validity.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Mar 2014 16:33:22 -0400 (EDT)

On Thu, 27 Mar 2014, Nicholas Weaver wrote:

>> 1 month validity.
>
> I said "don't give me that key roll crap" for a reason.

A bad reason.

> For an attacker, the root ZSK is not 1 month validity, since an attacker who's in a position to take advantage of such a ZSK compromise is going to be faking all of DNS for the target, and can therefore just as easily also fake NTP, ensuring that the attacker's key is still valid for most victims.

Than you have lost forever because we have used a 1024 key in the past.
You can always NTP attack them to today's 1024 key, and no increase in
key size in the future will help you.

> So you'd need to update the resolvers to either ignore <2048b root ZSKs or add in clock-ratchets, where the resolver never allows the clock to roll back more than a certain extent, or deploy a crypto-interactive NTP, etc....

If you can ignore old root keys, than you have already defeated your NTP
attack, in which case your "key roll crap" arguments falls as well.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Mar 2014 16:45:19 -0400

Nope.

ALL 1024 bit certs of every description are covered including end-entity.

On Thu, Mar 27, 2014 at 3:35 PM, Paul Wouters <[email-masked]> wrote:

>  Because the browsers have already decided killing of 1024b CAs is a good
>> idea, and they could revoke just those CAs once someone breaks a 1024b
>> example, since the browser vendors have good experience in revoking bad CAs
>> already (queue DigiNotar...)
>>
>
> 10-20 year validity.
>
>  In contrast, DNSSEC
>>
>
> 1 month validity.
>
> Paul
>
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Mar 2014 17:47:46 -0500

> Obligatory Snarky Note: these being the same people who, after 2007, said that, although you can create your own constants, you MUST still use the specified magic constants for Dual_EC_DRBG if you…

I wasn't defending the key size; I was just explaining how it was chosen by the team who signed the root zone. (We did a global roadshow to technical audiences laying out details such as key sizes, incidentally, and never got a single piece of feedback that 1024 was too small. So if there's blame for a poor decision to be apportioned, let's spread it round evenly and grimace shamefully, together.)

There was a plan underway to roll the KSK. I was at ICANN briefly when that started (I spoke publicly, albeit briefly about it in the dnsop meeting in Berlin). I'm no longer at ICANN and hence no longer have anything authoritative to say, but it seems plausible that the events leading up to NTIA's announcement the other week caused some delays or rescheduling of the KSK roll project. A KSK roll would be a good opportunity to change the key size.

There's a public consultation going on at ICANN about the future stewardship of the IANA Functions. I am aware that various technical/security groups are planning to submit comments. Drawing attention to potential weakness in the root zone ZSK as an operational input to that consultation does not seem like a horrible idea.

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Mar 2014 17:52:46 -0500

> There was a plan underway to roll the KSK. I was at ICANN briefly when that started (I spoke publicly, albeit briefly about it in the dnsop meeting in Berlin). I'm no longer at ICANN and hence no l…

Oh, heh, I just got off 20 hours of planes across the Pacific. It's the ZSK we're talking about. Choosing a different parameter for the ZSK doesn't necessarily involve IANA. Root zone KSK rollover not relevant.

I will go and find some coffee.

Joe

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 27 Mar 2014 15:54:47 -0700

On Mar 27, 2014, at 10:14 AM, Matthäus Wander <[email-masked]> wrote:
> 1024 bit: 1298238
> 2048 bit: 698232
> 1280 bit: 28441
> 4096 bit: 25326
> 512 bit:   8893
> 1536 bit: 385

Matthäus, do you have an easy way of separating out KSK from ZSK in your statistics?  FWIW, we’re currently doing 2048-bit KSK and 1024-bit ZSK, but will shortly be transitioning to 4096-and-2048.

                                -Bill

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Mar 2014 13:01:15 +0000

Paul Wouters <[email-masked]> wrote:

> > For an attacker, the root ZSK is not 1 month validity, since an attacker
> > who's in a position to take advantage of such a ZSK compromise is going to
> > be faking all of DNS for the target, and can therefore just as easily also
> > fake NTP, ensuring that the attacker's key is still valid for most victims.
>

I have a rough plan for how to avoid the insecure time replay vulnerability:
http://www.ietf.org/mail-archive/web/dnsop/current/msg11245.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Cyclonic becoming easterly or northeasterly later, 4 or 5,
occasionally 6 near iceland. Moderate or rough, occasionally very rough at
first. Rain or showers. Good, occasionally moderate.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Mar 2014 09:06:17 -0400

> http://www.ietf.org/mail-archive/web/dnsop/current/msg11245.html

Why is this needed?

Code is only vulnerable if it trusts 1024bit RSA. Code should not trust
1024bit RSA.

Therefore ICANN needs to sign the root zone with 2048 before we consider it
signed. End of story.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Mar 2014 09:11:10 -0400

> Therefore ICANN needs to sign the root zone with 2048 before we consider it

I think the point was that there was a time when the root was signed
(it happens to include now) with 1024 bit RSA, and if you want to
include that in the "signed period" then you need to accept that risk.
The selection of 1024 bits was done on the advice of those that some
people turn out now not to trust, but I think hindsight may be
different than foresight.

I don't think you can make the argument that the root zone is not
signed now, because if you do then in some future when 2048 bit RSA
turns out to be vulnerable, you'll have to repeat the argument.  That
seems absurd (it devolves to Zeno's zone signer).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Mar 2014 13:11:45 +0000

> > http://www.ietf.org/mail-archive/web/dnsop/current/msg11245.html

Some devices don't have battery-backed clocks. Some have broken clocks.
Private keys might get compromised rather than factorized.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth: Cyclonic at first in Plymouth, otherwise southeast
5 or 6. Slight or moderate, occasionally rough in Plymouth. Rain or thundery
showers. Moderate or good, occasionally poor.

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Mar 2014 09:50:45 -0400

On 28 Mar 2014, at 9:06, Phillip Hallam-Baker <[email-masked]> wrote:

> Therefore ICANN needs to sign the root zone with 2048 before we consider it signed. End of story.

Small point of clarity: the only key that ICANN maintains is the 2048 bit KSK, and the only signatures ICANN makes with it are over the DNSKEY RRSet. The 1024 bit ZSKs and signatures made by those keys are handled exclusively by the Root Zone Maintainer (Verisign).

It's not clear to me that any changes would be required at ICANN to accommodate 2048 bit ZSKs. As I recall, every KSR that is submitted for processing at a ceremony is carefully tested in dry runs before the date anyway, so even the existing QA could continue unchanged.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Mar 2014 10:26:52 -0400

On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley <[email-masked]> wrote:

> Small point of clarity: the only key that ICANN maintains is the 2048 bit
> KSK, and the only signatures ICANN makes with it are over the DNSKEY RRSet.
> The 1024 bit ZSKs and signatures made by those keys are handled exclusively
> by the Root Zone Maintainer (Verisign).
>
> It's not clear to me that any changes would be required at ICANN to
> accommodate 2048 bit ZSKs. As I recall, every KSR that is submitted for
> processing at a ceremony is carefully tested in dry runs before the date
> anyway, so even the existing QA could continue unchanged.
>

VeriSign is acting on ICANN's instructions. Burt Kaliski knows how to set
an RSA key length. If they take the decision the change will be made.

The root is signed using the ZSK which is 1024 bit. Ergo it is fair to say
that the root signatures are defective.

This is not an issue of hindsight. We have been phasing out 1024 bit certs
in the WebPKI since long before the Snowden disclosure. And unlike DNSSEC
we had the excuse of a very large legacy deployment to contend with.

The RSA768 break was the signal that RSA1024 was no longer to be considered
safe. When RSA 1536 is broken it will be time to go to the ECC schemes.

The reason that I can't see any ongoing risk from RSA1024 after we complete
the transition is that I expect sensible applications will (1) simply
discard RSA1024 bit signatures as invalid and (2) discard any signature
that purports to have been made before the time that the code was compiled.

I suggest that we adopt the following strategy:

1) Have some form of formal communication from the IETF to ICANN notifying
them that the RSA1024 signing is insecure.

2) Consider ways to avoid having future security requirements being
constantly compromised by the limit of one 1500 byte response packet on
UDP.

A more research oriented approach is that sites deploying DNSSEC create or
have issued an X.509v3 cert for their KSK and publish that in their zone.
That can then be used as a local trust anchor within the local network. It
can also be enrolled in Certificate Transparency.

One conclusion that should be drawn from the RSA1024 fiasco is that ICANN
is not in the business of cryptography and the current institutional
relationships are unsatisfactory. VeriSign is more than competent to make
the right decision. But the responsibility and decision power is split so
they don't actually have decision making power, nor does the IETF.

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Mar 2014 15:28:33 +0000

> And don't give me that key-roll BS: Give me an out of date key for . and a MitM position, and I can basically create a false world for many DNSSEC-validating devices by also providing bogus time da…

[Did not read all the discussion.]

Suppose I agree with the rationales for keys larger than 1024. Under 
some relatively paranoid assumptions in the threat model, they make sense.

Turning to the solution space, why not 1280 or 1459? Then increase by 
ever smaller jumps every two years.

Is it possible that the whole IT security community is social-engineered 
into thinking that anything below 2048 is inadequate for any purpose. 
Because the larger the RSA key size recommendations, the less severe the 
relative ECC performance cost on digital signature verification 
operations. Thus the ECC promoters have an in interest in the underlying 
expert community wisdom.

-- Thierry Moreau

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Mar 2014 11:41:57 -0400

On Fri, Mar 28, 2014 at 11:28 AM, Thierry Moreau <
[email-masked]> wrote:

>> And don't give me that key-roll BS: Give me an out of date key for . and
>> a MitM position, and I can basically create a false world for many
>> DNSSEC-validating devices by also providing bogus time data with a MitM on
>> NTP...
>>
>>
> Suppose I agree with the rationales for keys larger than 1024. Under some
> relatively paranoid assumptions in the threat model, they make sense.
>
> Turning to the solution space, why not 1280 or 1459? Then increase by ever
> smaller jumps every two years.
>
> relative ECC performance cost on digital signature verification operations.
> Thus the ECC promoters have an in interest in the underlying expert
> community wisdom.

No, its due to the math.

1024 bit is roughly an 80 bit work factor
2048 is roughly 112 bit work factor

This is the reason there is the expectation we have to move to EC
approaches. Longer RSA key sizes deliver diminishing returns.

The underlying problem is that the strength of RSA is strongly connected to
the distribution of primes. And even though primes become more scarce at
higher numbers, they do not become exponentially more scarce or else we
couldn't use 2048 bit RSA because it would take exponentially longer to
find the primes.

There are steps we could take to make RSA less of a burden. We could use
key compression for a start. It is actually possible to convey a 2048 bit
key in 1024 bits. We could also use one of the key compression schemes but
I am not sure if those are the source of the vulnerabilities that
discourage use of RSA.
-- 
Website: http://hallambaker.com/

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 28 Mar 2014 17:12:06 +0100

* Bill Woodcock [2014-03-27 23:54]:
> Matthäus, do you have an easy way of separating out KSK from ZSK in
> your statistics?  FWIW, we’re currently doing 2048-bit KSK and
> 1024-bit ZSK, but will shortly be transitioning to 4096-and-2048.

Yes, here you go:

KSK:
2048 bit: 668634
1024 bit:  49861
4096 bit:  22646
 512 bit:   2460
1280 bit:    812
1536 bit:    314

ZSK:
1024 bit: 1248377
2048 bit:   29598
1280 bit:   27629
 512 bit:    6433
4096 bit:    2680
1032 bit:     310

Regards,
Matt

- --

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Mar 2014 14:29:52 -0400

On 28 Mar 2014, at 10:26, Phillip Hallam-Baker <[email-masked]> wrote:

> VeriSign is acting on ICANN's instructions.

I think actually that Verisign is acting on NTIA's instructions under the cooperative agreement. But my experience while I was there was that the three organisations work in concert on this kind of thing and don't make changes in isolation.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Mar 2014 15:11:52 -0400

On Fri, Mar 28, 2014 at 2:29 PM, Joe Abley <[email-masked]> wrote:

> I think actually that Verisign is acting on NTIA's instructions under the
> cooperative agreement. But my experience while I was there was that the
> three organisations work in concert on this kind of thing and don't make
> changes in isolation.
>

The risk here is that everyone is going to assume that the right thing is
being done because VeriSign is the party doing it.

But VeriSign does not have decision making power here and they are unable
to exercise either exit or voice.