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

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Apr 2014 02:36:58 -0700

At 15:47 27-03-2014, Joe Abley wrote:
>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.

Yes, assuming that there is a reason for such a change [1].

I could not find any report about the outcome of the Rollover consultation.

Regards,
S. Moonesamy

1. "To date, despite huge efforts, no one has broken a regular 
1024-bit key;  in fact, the best completed attack is estimated to be 
the equivalent of a 700-bit key.  An attacker breaking a 1024-bit 
signing key would need to expend phenomenal amounts of networked 
computing power in a way that would not be detected in order to break 
a single key. Because of this, it is estimated that most zones can 
safely use 1024-bit keys for at least the next ten years."  That was 
the IETF Consensus in 2012.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Apr 2014 08:39:11 -0400

On Mar 27, 2014, at 6:54 PM, Bill Woodcock <[email-masked]> wrote:

> 
> On Mar 27, 2014, at 10:14 AM, Matthäus Wander <[email-masked]> wrote:
>> 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
> 
> 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
> 

Doing these big jumps is the wrong thing to do, increasing the key size increases three things:
	time to generate signatures  
	bits on the wire
	verification time. 

I care more about verification time than bits on the wire (as I think that is a red herring).
Signing time increase is a self inflicted wound so that is immaterial. 

                  sign    verify    sign/s verify/s
rsa 1024 bits 0.000256s 0.000016s   3902.8  62233.2
rsa 2048 bits 0.001722s 0.000053s    580.7  18852.8
rsa 4096 bits 0.012506s 0.000199s     80.0   5016.8

Thus doubling the key size decreases the verification performance by roughly by about 70%. 

KSK's verification times affect the time to traverse the DNS tree, thus 
If 1024 is too short 1280 is fine for now
If 2048 is too short 2400 bit key is much harder to break thus it should be fine. 

just a plea for key use policy sanity not picking on Bill in any way.

	Olafur

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 1 Apr 2014 06:04:37 -0700

> Signing time increase is a self inflicted wound so that is immaterial. 

Agreed…  Signing time is our problem to manage as a budgetary matter.  Bits on the wire seem too small, relative to the overall stream of traffic, to be of any significance.  But...

> rsa 4096 bits 0.012506s 0.000199s     80.0   5016.8

…you think the difference between 53 uSec and 199 uSec is material for end-users?  Even if they have to traverse several levels of zones signed at 4096 bits?

There’s also the issue that we have to plan some time in advance for changes like this, and by the time the change is actually in production, these times will have dropped still further.  So, I agree, incremental and continuous upgrading of key-lengths is necessary to counter brute-force attacks, but I’m not sure I want the granularity to be so fine that I’m rolling KSKs all the time.

                                -Bill

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Apr 2014 06:05:20 -0700

> just a plea for key use policy sanity not picking on Bill in any way.

NO!  FUCK THAT SHIT.  Seriously.

There is far far far too much worrying about "performance" of crypto, in cases like this where the performance just doesn't matter!

Yes, you can only do 18K verifies per CPU per second for 2048b keys.  Cry me a river.  Bite the bullet, go to 2048 bits NOW, especially since the servers do NOT have resistance to roll-back-the-clock attacks.

In a major cluster validating recursive resolver, like what Comcast runs with Nominum or Google uses with Public DNS, the question is not how many verifies it can do per second per CPU core, but how many verifies it needs to do per second per CPU core.

And at the same time, this is a problem we already know how to parallelize, and which is obscenely parallel, and which also caches...

Lets assume a typical day of 1 billion external lookups for a major ISP centralized resolver, and that all are verified.  Thats less 1 CPU core-day to validate every DNSSEC lookup that day at 2048b keys.  

And yeah, DNS is peaky, but that's also why this task is being run on a cluster already, and each cluster node has a lot of CPUs.

--
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: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Apr 2014 09:39:54 -0400

On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
<[email-masked]>wrote:

> There is far far far too much worrying about "performance" of crypto, in
> cases like this where the performance just doesn't matter!
>
> Yes, you can only do 18K verifies per CPU per second for 2048b keys.  Cry
> me a river.  Bite the bullet, go to 2048 bits NOW, especially since the
> servers do NOT have resistance to roll-back-the-clock attacks.
>
>
>
> In a major cluster validating recursive resolver, like what Comcast runs
> with Nominum or Google uses with Public DNS, the question is not how many
> verifies it can do per second per CPU core, but how many verifies it needs
> to do per second per CPU core.
>
> And at the same time, this is a problem we already know how to
> parallelize, and which is obscenely parallel, and which also caches...
>
> Lets assume a typical day of 1 billion external lookups for a major ISP
> centralized resolver, and that all are verified.  Thats less 1 CPU core-day
> to validate every DNSSEC lookup that day at 2048b keys.
>

Yes, I agree, but you are proposing a different DNSSEC model to the one
they believe in.

The DNS world has put all their eggs into the DNSSEC from Authoritative to
Stub client model. They only view the Authoritative to Resolver as a
temporary deployment hack.

So they resisted the idea of an authenticated Stub-client <-> Resolver
protocol and they dumb down the crypto so their model will work.

Weakening the crypto algorithms to make the architecture work is always a
sign that the wrong architecture is being applied.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Apr 2014 06:44:43 -0700

On Apr 1, 2014, at 6:39 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Yes, I agree, but you are proposing a different DNSSEC model to the one they believe in.
> 
> The DNS world has put all their eggs into the DNSSEC from Authoritative to Stub client model. They only view the Authoritative to Resolver as a temporary deployment hack.

And in that case (which is, I agree, what is needed), the time to verify really doesn't matter one fucking bit, since those clients really won't care about an extra 50 MICROseconds to validate the crypto.  Heck, they won't notice 50 milliseconds...

> Weakening the crypto algorithms to make the architecture work is always a sign that the wrong architecture is being applied.

And weakening the crypto needlessly like this is even worse.  IMO, all DNSSEC software should simply refuse to generate <2048b RSA keys.

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 1 Apr 2014 15:52:28 +0200

On 04/01/2014 03:39 PM, Phillip Hallam-Baker wrote:
> The DNS world has put all their eggs into the DNSSEC from Authoritative
> to Stub client model. They only view the Authoritative to Resolver as a
> Weakening the crypto algorithms to make the architecture work is always
> a sign that the wrong architecture is being applied.
> 

Oh come on.

If anything, one would expect that doing the validation on the end
machines is *easier* despite needing more cycles to do so, since there
is much less work to do and generally much more cycles to spare. So I
don't see your reasoning about 'them' follow up into this conclusion here.

The way I read it, Olafur is asking for people to consider other sizes,
and operational issues, rather than simply saying "double 'em up,
yeeha". One may disagree (I do too, as it happens, for different
reasons), or one can consider it and still come to the conclusion that
2048/4096 are the only right sizes (for now, we'll need better algos
soonish I guess).

Jelte

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 08:15:36 -0700

> Thus doubling the key size decreases the verification performance by

With those numbers; if the validating resolver uses speculative/optimistic
concurrency [1] then jumping from 1024 to 4096 bits, the user-impact is
that ~180us are added to the overall resolution time. Zero in the cached
case.

There is an impact on the overall capacity of the resolver, though it's a
function of cache-miss-rate (since cache hits need not be verified). Large
centralised resolver operators may face some pressure (anyone doing
validation locally is unlikely to notice), but is it sensible to compromise
your zone security to accommodate that?

[1] There's no need to wait for a response to be validated before
recursing, a validating resolver can first recurse and later backtrack if
the parent signature doesn't verify.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 10:50:21 -0700

On Tue, Apr 1, 2014 at 6:39 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver <[email-masked]
> > wrote:
>

I think even in the imagined future of validating stub resolvers, there's
still value in centralized caching; it speeds up lookup times. There's no
sense in intermediates caching bad answers, especially since it can lead to
denial of service, so there's still some value in validating centrally too.

-- 
Colm

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Apr 2014 09:39:43 +1100

In message <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=[email-masked]>
> temporary deployment hack.

As I have said many times.  There is a myth that recursive servers
do not need to validate answers.  Recursive servers will always
need to validate answers.  Stub resolvers can't recover from recursive
servers that pass through bogus answers.  Stub resolvers/applications
also need to validate answers.

Always set CD=1 is also bad advice.  Stub resolvers need to send
both CD=1 and CD=0 queries and should default to CD=0.  CD=1 should
be left to the case where they get a SERVFAIL result to the CD=0
to handle the case where the recursive server's clock is broken or
it has a bad trust anchor.

> protocol and they dumb down the crypto so their model will work.

DNSSEC is quite capable to protecting that path.  Why do you need
a second protocol.

> --089e0158b87c9c259504f5fb4d95
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
> _quote">On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver <span dir=3D"ltr">&=
> lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">nweaver@i=
> csi.berkeley.edu</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><div class=3D""><br>
> On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson &lt;<a href=3D"mailto:ogud@o=
> gud.com">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> </div><div class=3D"">&gt; Doing these big jumps is the wrong thing to do, =
> increasing the key size increases three things:<br>
> &gt; =A0 =A0 =A0 time to generate signatures<br>
> &gt; =A0 =A0 =A0 bits on the wire<br>
> &gt; =A0 =A0 =A0 verification time.<br>
> &gt;<br>
> &gt; I care more about verification time than bits on the wire (as I think =
> that is a red herring).<br>
> &gt; Signing time increase is a self inflicted wound so that is immaterial.=
> <br>
> &gt;<br>
> &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sign =A0 =A0verify =A0 =A0sign/s ve=
> rify/s<br>
> &gt; rsa 1024 bits 0.000256s 0.000016s =A0 3902.8 =A062233.2<br>
> &gt; rsa 2048 bits 0.001722s 0.000053s =A0 =A0580.7 =A018852.8<br>
> &gt; rsa 4096 bits 0.012506s 0.000199s =A0 =A0 80.0 =A0 5016.8<br>
> &gt;<br>
> &gt; Thus doubling the key size decreases the verification performance by r=
> oughly by about 70%.<br>
> &gt;<br>
> &gt; KSK&#39;s verification times affect the time to traverse the DNS tree,=
>  thus<br>
> &gt; If 1024 is too short 1280 is fine for now<br>
> &gt; If 2048 is too short 2400 bit key is much harder to break thus it shou=
> ld be fine.<br>
> &gt;<br>
> &gt; just a plea for key use policy sanity not picking on Bill in any way.<=
> br>
> <br>
> </div>NO! =A0FUCK THAT SHIT. =A0Seriously.<br>
> <br>
> There is far far far too much worrying about &quot;performance&quot; of cry=
> pto, in cases like this where the performance just doesn&#39;t matter!<br>
> <br>
> Yes, you can only do 18K verifies per CPU per second for 2048b keys. =A0Cry=
>  me a river. =A0Bite the bullet, go to 2048 bits NOW, especially since the =
> servers do NOT have resistance to roll-back-the-clock attacks.<br>
> <br>
> <br>
> <br>
> In a major cluster validating recursive resolver, like what Comcast runs wi=
> th Nominum or Google uses with Public DNS, the question is not how many ver=
> ifies it can do per second per CPU core, but how many verifies it needs to =
> do per second per CPU core.<br>
> 
> <br>
> And at the same time, this is a problem we already know how to parallelize,=
>  and which is obscenely parallel, and which also caches...<br>
> <br>
> Lets assume a typical day of 1 billion external lookups for a major ISP cen=
> tralized resolver, and that all are verified. =A0Thats less 1 CPU core-day =
> to validate every DNSSEC lookup that day at 2048b keys.<br></blockquote>
> <div><br></div><div><br></div><div>Yes, I agree, but you are proposing a di=
> fferent DNSSEC model to the one they believe in.</div><div><br></div><div>T=
> he DNS world has put all their eggs into the DNSSEC from Authoritative to S=
> tub client model. They only view the Authoritative to Resolver as a tempora=
> ry deployment hack.</div>
> <div><br></div><div>So they resisted the idea of an authenticated Stub-clie=
> nt &lt;-&gt; Resolver protocol and they dumb down the crypto so their model=
>  will work.=A0</div></div><div><br></div><div><br></div><div>Weakening the =
> crypto algorithms to make the architecture work is always a sign that the w=
> rong architecture is being applied.</div>
> <div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
> allambaker.com/</a><br>
> </div></div>
> 
> --089e0158b87c9c259504f5fb4d95--
> 
> 
> --===============8670379042506024621==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============8670379042506024621==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 17:07:46 -0700

On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews <[email-masked]> wrote:
> servers that pass through bogus answers.

This too is going too far; of course they can, they can ask another
recursive resolver.

> it has a bad trust anchor.

Defaulting to CD=0 renders DNSSEC, essentially, pointless. Resolvers, and
the path between resolvers and stubs, are the easiest components in the
lookup chain to subvert.

> DNSSEC is quite capable to protecting that path.  Why do you need

That statement is not consistent with setting CD=0 on that path.

-- 
Colm

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Apr 2014 11:31:59 +1100

In message <CAAF6GDe=[email-masked]>, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writ
es:
> --089e011825440f264b04f604135f
> Content-Type: text/plain; charset=ISO-8859-1
> 

Which also passes through bogus answers.  I will repeat stub resolvers
can't recover from recursive servers that pass through bogus answers.

> the path between resolvers and stubs, are the easiest components in the

CD=0 tells the resolver to validate the answers it getsi if it is
validating.  It has NOTHING to do with whether you are validating
or not.  You have fallen for the myth that CD=1 indicates that you
intend to validate and that CD=0 means that you are not validating.
CD DOES NOT HAVE THOSE MEANINGS.

DO=1 is the ONLY bit REQUIRED to be set if you are validating.

If DO=1 is set you should assume the client may be validating.
Named assumes this when deciding if it will intentionally break
DNSSEC validation down stream.

> That statement is not consistent with setting CD=0 on that path.

I sugges that you go re-read all the DNSSEC RFC's if you believe
that because you are categorically WRONG.
 
> -- 
> Colm
> 
> --089e011825440f264b04f604135f
> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
> ue, Apr 1, 2014 at 3:39 PM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"m=
> ailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<=
> blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
>  #ccc solid;padding-left:1ex">
> As I have said many times. =A0There is a myth that recursive servers<br>
> do not need to validate answers. =A0Recursive servers will always<br>
> need to validate answers. =A0Stub resolvers can&#39;t recover from recursiv=
> e<br>
> servers that pass through bogus answers. =A0</blockquote><div><br></div><di=
> v>This too is going too far; of course they can, they can ask another recur=
> sive resolver.</div><div><br></div><blockquote class=3D"gmail_quote" style=
> =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 
> Always set CD=3D1 is also bad advice. =A0Stub resolvers need to send<br>
> both CD=3D1 and CD=3D0 queries and should default to CD=3D0. =A0CD=3D1 shou=
> ld<br>
> be left to the case where they get a SERVFAIL result to the CD=3D0<br>
> to handle the case where the recursive server&#39;s clock is broken or<br>
> it has a bad trust anchor.<br></blockquote><div><br></div><div>Defaulting t=
> o CD=3D0 renders DNSSEC, essentially, pointless. Resolvers, and the path be=
> tween resolvers and stubs, are the easiest components in the lookup chain t=
> o subvert.=A0<br>
> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
> er-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
> &gt; So they resisted the idea of an authenticated Stub-client &lt;-&gt; Re=
> solver<br>
> &gt; protocol and they dumb down the crypto so their model will work.<br>
> <br>
> </div>DNSSEC is quite capable to protecting that path. =A0Why do you need<b=
> r>
> a second protocol.<br></blockquote><div><br></div><div>That statement is no=
> t consistent with setting CD=3D0 on that path.=A0</div></div><div><br></div=
> >-- <br>Colm
> </div></div>
> 
> --089e011825440f264b04f604135f--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 18:25:12 -0700

> can't recover from recursive servers that pass through bogus answers.

DNSSEC is a mitigation against spoofed responses, man-in-the-middle
interception-and-rewriting and cache compromises. These threats are
endpoint and path specific, so it's entirely possible that one of your
resolvers (or its path) has been compromised, but not others. If all of
your paths have been compromised, then there is no recovery; only
detection. But that is always true for DNSSEC.

> DNSSEC validation down stream.

As you pointed out, if I set CD=1, I always expect a meaningful answer
containing signatures that I can validate. If I set CD=0, then an empty
SERVFAIL response is valid. If I get SERVFAIL, how do I validate that it's
a real error? Your suggestion is to regress to the CD=0 case and re-check
it (or maybe do your own recursion?). Why not just do CD=0 all along?

Now I agree that a resolver should always validate the signatures anyway,
and if I were writing a caching resolver, I'd never cache rrsets that fail
validation, even if the user has CD set to 1. But that's separate.

> that because you are categorically WRONG.

Please stay civil, and also please don't assume that I haven't read the
DNSSEC RFCs.

If you set CD=0, you can't authenticate the failure case, empty SERVFAILs
can be spoofed or inserted towards the stub. And how do you disambiguate
between SERVFAILs that are validation errors and other server failures?
Without some kind of resolver redundancy (so recovering via retrying
another resolver) I don't see a way. Of course if all of your resolvers
return SERVFAIL, you're left in the same situation - but again, if every
path you have has been compromised, there is no escape.

But this can all be boiled down to;  As you've already written, you agree
that CD=1 is necessary in the failure case - it's the only hope of
authenticating the error. So why bother with CD=0 at all?

-- 
Colm

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Apr 2014 22:37:54 -0400

> NO!  FUCK THAT SHIT.  Seriously.

Watch your language, just because I'm calling you on the carpet for simplistic world view, does not mean you need to use foul language. 

> There is far far far too much worrying about "performance" of crypto, in cases like this where the performance just doesn't matter!

disagree strongly, you are only looking at a part of the whole picture. 
Verification adds resolution latency + verification adds extra queries which is more latency
	latency == un-happy eye-balls.  

> Yes, you can only do 18K verifies per CPU per second for 2048b keys.  Cry me a river.  Bite the bullet, go to 2048 bits NOW, especially since the servers do NOT have resistance to roll-back-the-clo…

Why not go to a good ECC instead ? (not sure which one, but not P256 or P384) 

18K answers/second ==> is a fraction of what larger resolver servers do today during peak times, yes not all answers need validation.
BUT you need to take into account that in some cases there is going to be lots of redundancy in verification in large resolver clusters, thus
if your query stream hits 5 different hosts all of them may end up doing almost 5x of the work, thus adding servers does not scale. 
Yes people can create any cast clusters in depth where only the front end ones do verification and the back end ones only answer queries, but
that has different implications. 

Remember it is not average load that matters it is peak load, even if the peak for 30 minutes on one day of the year. 

Over the years I have been saying use keys that are appropriate, thus for someone like Paypal it makes sense to have strong keys,
but for my private domain does it matter what key size I use? 
I do not buy the theory that one size fits all model for crypto, people should not use unsafe crypto, but the one size fits all is not the
right answer, just like not every zone needs a KSK and ZSK split. ( I use single 1280 bit RSA key with NSEC) 

A real world analogy is that not everyone needs the same kind of car, some people need big cars, others small ones or even no car. 

Furthermore using larger keys than your parents is non-sensical as that moves the cheap point of key cracking attack. 
 
> In a major cluster validating recursive resolver, like what Comcast runs with Nominum or Google uses with Public DNS, the question is not how many verifies it can do per second per CPU core, but ho…

I have no doubt that CPU's can keep up but the point I was trying to make is increasing the key sizes by this big jump 
==> invalidates peoples assumptions on what the load is going to be in the near term. 

> 
> And at the same time, this is a problem we already know how to parallelize, and which is obscenely parallel, and which also caches…

Do we? Some high performance DNS software is still un-treaded, many resolvers are run in VM's with low number of cores 
exported to the VM. 

> Lets assume a typical day of 1 billion external lookups for a major ISP centralized resolver, and that all are verified.  Thats less 1 CPU core-day to validate every DNSSEC lookup that day at 2048b…

1B is low due to low TTL's and synthetic names used for transactions, and as I said before it is peak load that matters not average. 
DNSSEC processing is just a part of the whole processing model. 

> And yeah, DNS is peaky, but that's also why this task is being run on a cluster already, and each cluster node has a lot of CPUs.

that costs money, and effort to operate.

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Apr 2014 22:45:52 -0400

On Apr 1, 2014, at 11:15 AM, Colm MacCárthaigh <[email-masked]> wrote:

> With those numbers; if the validating resolver uses speculative/optimistic concurrency [1] then jumping from 1024 to 4096 bits, the user-impact is that ~180us are added to the overall resolution time. Zero in the cached case. 
> 

you are assuming one validation per question ? 
what if the resolver needs to to 10? that is 1.8ms, 

> There is an impact on the overall capacity of the resolver, though it's a function of cache-miss-rate (since cache hits need not be verified). Large centralised resolver operators may face some pressure (anyone doing validation locally is unlikely to notice), but is it sensible to compromise your zone security to accommodate that?

What is the security model ? 
without defining that we can not discuss "compromise" in practical terms. 
In my mind the question is what is the value of breaking key for "X", and the value depends on who/what "X" is. 
How valuable is it to anyone to break the key for ogud.com vs amazon.com ? 
As amazon.com is more valuable they SHOULD use stronger keys at all times, but .com key is even more valuable.

In all system design we need to take into account where the system can be subverted, right now the 
registration part of DNS system is the weakest link, thus most cost effective way to gain hold of a domain is to 
divert the registration. 

Secondly what can someone do with "cracked" key and for how long?  

> 
> [1] There's no need to wait for a response to be validated before recursing, a validating resolver can first recurse and later backtrack if the parent signature doesn't verify.

In the scope of things verification times are small compared to network delays but can add up if done as batch operation. 

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Apr 2014 19:48:24 -0700

> Why not go to a good ECC instead ? (not sure which one, but not P256 or P384) 

Why not P256 or P384? They are the most-studied curves. Some of the newer curves do have advantages, but they are also newer.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Wed, 2 Apr 2014 02:49:19 +0000

> detection. But that is always true for DNSSEC.

Consider the scenario in which one authoritative server for a zone
has been compromised and the others have not, and that one happens to
have the lowest round-trip time, so it's favored by your resolver.

If you query with CD=0, a validating resolver detects the problem
and tries again with another auth server.  It doesn't give up until
the whole NS RRset has failed.

If you query with CD=1, you get the bogus data and it won't validate.
If you try again, you'll get the same bogus data out of the cache.
Use a different resolver, and if it happens to use the same auth
server, then the same thing happens again.

Your best chance of getting an answer that you can validate is to
send CD=0 to a recursive resolver that is itself validating.  If you get
SERVFAIL, *then* you try with CD=1, and if the result validates, you
know it was the resolver that was broken rather than the data.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Apr 2014 13:50:54 +1100

In message <CAAF6GDdLs3V9JMa8jgD_asYqhmt=[email-masked]>
> detection. But that is always true for DNSSEC.

There is also the good answers mixed in with the bad answers coming
to the recursive server which is supposed to discard the bad answers
and wait for the good answer which will be in the query stream.

> a real error?

You re-check with CD=1.

> Your suggestion is to regress to the CD=0 case and re-check

CD=1 is for bad trust anchors / clocks in the validating recusive server.
CD=0 is for attacker sending spoofed traffic at the recursive server.

Different fail/attack profiles, different query bits needed.

The recursive server sorts the wheat from the chaff and passes the
stub resolver the wheat.

> between SERVFAILs that are validation errors and other server failures?

You retry with CD=1, which I stated initially.  Note if the recursive
server is returning SERVFAILs to CD=0 it will be causing problems
for all its clients so will likely be fixed.  Additionally CD=0 helps
when the recursive server mis-classifies authoritative servers as not
supporting EDNS.

> authenticating the error. So why bother with CD=0 at all?

Because CD=1 does not get the good answers to the stub when the
responses to the recursive server are being spoofed.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Apr 2014 22:58:54 -0400

> it has a bad trust anchor.

It strikes me that this argument has been hashed pretty well to death
before, but just to refresh everyone's memory, there are several
different strategies one can use here:

1.  CD=1 all the time, and if you get into trouble consider the
failure a feature.  Mark's argument (which has some merit) is that
this is too strong, because if the stub gets the bogus answer, it
can't "fall through" and pick up another one that might be good.

2.  CD=1 mostly, and if you get a failure try falling back to CD=0.
Maybe with CD=0, the recursive server will find you something that
validates in order to get you on your way.

3.  The opposite of (2), defauling to CD=0 (what Mark advocates).  

4.  Give up on stubs and be a full service resolver all the time.

For 1-3, people may have a peek at RFC 6840, especially section 5.9
and Appendix B.

None of this, AFAICT, helps us at all with the 1024/2048 choice.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Apr 2014 23:02:07 -0400

> Why not P256 or P384? They are the most-studied curves. Some of the newer curves do have advantages, but they are also newer.

The verification performance is bad, P256 takes 24x times longer to verify a signature than 2048 bit RSA key. 
Studied != good performance

	Olafur

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 20:02:54 -0700

> what if the resolver needs to to 10? that is 1.8ms,

I'm not :) as I wrote - if the resolver validates after it has recursed,
only the final end of the line validation increases the overall latency.
Responses can be assumed to be valid, recursed and then that recursion can
be cancelled and backtracked if the response is found to be invalid.

In all system design we need to take into account where the system can be
> subverted, right now the
> registration part of DNS system is the weakest link, thus most cost
> effective way to gain hold of a domain is to
> divert the registration.
>

 There are several weak links, and it makes sense to work on them all.

> In the scope of things verification times are small compared to network
> delays but can add up if done as batch operation.
>

Optimistic concurrency doesn't imply batching. Each response can be
validated, while the next question is awaiting a response - one at a time.

-- 
Colm

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Apr 2014 23:06:37 -0400 (EDT)

> but for my private domain does it matter what key size I use?

That depends. How much money is in your [email-masked] paypal account?

Seriously though, security strength should not depend on who uses
it. Just like opensource software does not tell you for what you can
use the software. No one can make consistent judgement calls on that.

We already see security that is only available to "important
players", like EV certificates, and browser vendors pinning their own
certificates, OS vendors hardcoding their IP addresses. It's a position
of priviledge. We should not design or deploy to accomodate that. One
the of advantages of DNSSEC is that we can give everyone the highest
levels of security. Don't make a security economy class.

People running giant DNS resolver farms can add a few boxes to their
farm. People running resolvers on the stub can take the extra hit for
the few domains they are resolving.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Apr 2014 14:23:50 +1100

> For 1-3, people may have a peek at RFC 6840, especially section 5.9

And I pointed out before RFC 6840 was published that the appendix
was incomplete in its analysis.  You didn't want to reopen the
analysis, as it was a long discussion to get what was there, and
the wg, I suspect, was too fried to care one way or the other.  As
a result we have to deal with the fallout now.

> None of this, AFAICT, helps us at all with the 1024/2048 choice.

Actually it does as it shows that recursive servers need to validate.
If you are looking at workload you have to factor that into the
analysis.

Mark

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Apr 2014 21:10:54 -0700

Pardon my language, but you are repeating the same bogus performance arguments that have hurt crypto for years.  Having heard the same thing, over and over and over again, over the better part of a decade and change, it really does get to me.

Symmetric key is effectively free on a modern computer (even when AES first came out you could do nearly a gigabit on a single core.  Try getting a gigabit of I/O into or out of a circa 2001 PC), and even slow-old RSA, especially RSA validation, is close enough to free for practical purposes.

And when you do have big load on a server serving many clients in the very rare case where the crypto IS the critical bottleneck, this is an obscenely parallel task... 

> 	latency == un-happy eye-balls.  

You are talking about 50 microseconds of additional latency for using a real key length instead of 1024b lengths.  Not milliseconds.  Microseconds.

3e8 m/s * 1e-6s/us is 300m/us.  So thats 15 kilometers of network travel if you remove all switches and lay down a vacuum cable.

And remember, its not on the critical path except for the final validation, because you can use glue before it validates to do your lookups and validate the upper pieces of the hierarchy while waiting for the lower pieces to arrive, and well, its going to take a lot longer than 50 microseconds for that data to arrive.

I don't see HFT systems doing DNSSEC validation...

> that has different implications. 

If the crypto is too much time in your cluster resolver, hash(name) to find cluster node that already has the answer.  These have known, off the shelf solutions in the unlikely event that such a key length jump makes a difference.

> Remember it is not average load that matters it is peak load, even if the peak for 30 minutes on one day of the year. 

And even in that universal deployment case, of 10x the load of the average case, that is a whopping 10 CPU cores to do the crypto for a 1B lookup/day case.  Thats less than a single server these days.

1B uncached lookups is a lot.  This is a big number for things that are largely driven by human processes and which (even in the nightmare that is CDNs and 10s TTLs), cache, and which ISPs distribute close to the end user to save latency.

Oh, and unless the CDN is doing dynamic signing, the RRSIG TTLs are much longer, so the crypto operations cache for a lot longer TTL.

> A real world analogy is that not everyone needs the same kind of car, some people need big cars, others small ones or even no car. 

But at the same time, we mandate certain crash resistance.  RSA keys of less than 2048b should be deprecated, and DNSSEC software MUST NOT generate them.  

We do not sell cars with bodies made of silly putty and airbags made from party balloons, we SHOULD NOT deploy software with known unsafe key lengths.

> Furthermore using larger keys than your parents is non-sensical as that moves the cheap point of key cracking attack. 

And why do you think I'm so pissed at the root, and com, and everyone else using 1024b keys?

Thats a joke, a bad one, and it needs to be fixed, and it needs to be fixed to be a real value, and real value, based on real cryptographers recommendations dating back the better part of a decade is 2048b.

> ==> invalidates peoples assumptions on what the load is going to be in the near term. 

How many resolvers are currently spending more than 10% of CPU doing DNSSEC validation right now?  Any above 1%?

> Do we? Some high performance DNS software is still un-treaded, many resolvers are run in VM's with low number of cores 

Who is running a major centralized ISP (1M+ customers on a single resolver instance, 1B+ external lookups/day) on a un-threaded, low powered system for DNS yet doing DNSSEC validation?

The systems you are talking about are in the 100M external lookup range or less, and in that case the crypto really doesn't matter to the performance.  Oh, and they aren't validating anyway, so who cares?

> DNSSEC processing is just a part of the whole processing model.

1B external lookups is a number taken from when I was looking at SIE data (which captures the queries from the participating recursive resolvers) about a year ago to detect covert channels.

It was ~2B/day lookups in the data set, but there were multiple major cluster resolvers belonging to a single top 10 US ISP which dominated that dataset.

Even assuming peak load 10x average (an unrealistic amount of peakiness if you've ever looked at network traffic graphs), and every answer has to validate once (yes, you may have a few more, but in practice this caches as well, since all 1B lookups are not going to be to 1B different domains...), thats still just 10 CPU cores.  

The nearly 2-year-old mac mini on my desktop is a quad core.  If your billion lookup a day DNS resolver is validating DNSSEC, everything is signed, yet you  can't afford to run on a single modern dual-CPU oct-core system, you get no sympathy from me.

> that costs money, and effort to operate.

Effort?  How?  The assumption is you are already going through the hassle of validation.

Money?  You're talking peanuts.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Apr 2014 00:27:57 -0400

On Wed, Apr 02, 2014 at 02:23:50PM +1100, Mark Andrews wrote:

> was incomplete in its analysis.

For whatever it's worth, my recollection is that, among other things,
you offered the sort of calm, reasoned, fully-explained analysis that
you and Nick Weaver seem to be competing to offer in this discussion,
with the all-caps lines and everything.  But in any case, since that
was another WG and since that document is published, I'm not sure the
value in debating the history.

There _is_ discussion of some of these issues in 6840, and I think it
is helpful for people to have read it.  It would not surprise me, of
course, if it turned out that 6840 or any other document about the DNS
turned out to have some issues.

> Actually it does as it shows that recursive servers need to validate.

No, it shows that under some use cases the recursive server will
provide better results if it validates, which is subtly different from
what you say there.  "Need to" is too strong.  "Undesirable things
happen if not" might be true.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Apr 2014 22:24:34 -0700

> If you query with CD=1, you get the bogus data and it won't validate.

I don't think this makes much sense for a coherent resolver. If I were
writing a resolver, the behaviour would instead be;  try really hard to
find a valid response, exhaust every reasonable possibility. If it can't
get a valid response, then if CD=1 it's ok to pass back the invalid
response and its supposed signatures - maybe the stub will no better, at
least fail open. If CD=0, then SERVFAIL, fail closed.

Although CD means "checking disabled", I wouldn't actually disable
checking, simply because that's stupid (I don't mean to be impolite, but I
don't have a better word to use here). But by preserving the on-the-wire
semantics of the CD bit, I'd preserve effectiveness as a cache, and pass on
what's needed to validate even the failure cases.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Apr 2014 22:37:57 -0700

On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh <[email-masked]> wrote:
>  
> I don't think this makes much sense for a coherent resolver. If I were writing a resolver, the behaviour would instead be;  try really hard to find a valid response, exhaust every reasonable possibility. If it can't get a valid response, then if CD=1 it's ok to pass back the invalid response and its supposed signatures - maybe the stub will no better, at least fail open. If CD=0, then SERVFAIL, fail closed. 

The bigger problem is not the CD case, but getting the data at all to validate locally.  

A lot (and I mean a LOT) of NATs give a DNS proxy that doesn't understand or forward requests for DNSSEC information. Heck, even Apple (which in my opinion makes the best overall CPE) doesn't do this right.  These NATs don't give the IP of the real recursive resolver, which often does support DNSSEC (and, in the case of Comcast, even validates).

Which means you have to go around and do a full local fetch, starting at the root and going down from there to validate on the client.

And then, to make matters worse, you have the hotspots and similar cases which force the user to use the configured recursive resolver.  Fortunately, most of those support fetching DNSSEC records.  But note that I said most, not all....

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Apr 2014 07:38:22 -0400

On Tue, Apr 1, 2014 at 10:48 PM, Paul Hoffman <[email-masked]> wrote:

> Why not P256 or P384? They are the most-studied curves. Some of the newer
> curves do have advantages, but they are also newer.
>

Same answer as always: A patent troll with the most worthless claim ever is
still going to cost $4 million to get a declarative judgement against.

RIM is on the verge of bankruptcy and it is very likely the patents will be
acquired by a troll.

And the new tactic is to go after the customers, not the technology
providers. So without the declarative judgement we are swapping a
technology we know we have no problem with for one with an expensive
liability. So we definitely need a declarative judgement.

IF the size of the signatures vs the packet size was the issue we could go
to DSA. It has some implementation issues but I'll take 2048 bit DSA over
1024 bit RSA.

Alternatively, we can forget the ICANN root as being the primary validation
path and have people publish a 2048 bit cert in a WebPKI validated chain in
their zone. We already have the records for that.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Apr 2014 09:30:42 -0400

After a break of a few months I rejoined the DNSOP WG mail list. After the very first message I sent a complaint to the chairs over the tone and language.  I feel I should send a note about that to the open list itself.

It’s not that I have a puritan tongue.  It’s that such low-brow language, including the subject line’s obtuse reference to an obscene expression and finally to the out right vulgar expression in the thread call into doubt the level of professionalism of this WG.  It’s hard to defend the work that results from a group that exhibits juvenile behavior.  I realize that I am reacting to perhaps the writing of one person (perhaps, I never tried to verify the originator) and perhaps reacting to the interaction of a small group of individuals - even if some are well-intentioned here.  But I think that it is up to the WG to defend it’s stature and not accommodate this low level of discourse.

As to the matter at hand, I had been an operator of DNS services for about the past decade, designed the initial role out of DNSSEC in places, and ran a measurement experiment for a few years to quantify the choices.

I found that there are two primary reasons why 1024 bits is used in zone signing keys.

 One - peer pressure.  Most other operators start out with 1024 bits.  I know of some cases where operators wanted to choose other sizes but were told to “follow the flock.”

Two - it works.  No one has ever demonstrated a failure of a 1024 bit key to provide as-expected protection.

From these two main reasons (and you’ll notice nothing about cryptographic strength in there) a third very import influence must be understood - the tools operators use more or less nudge operators to the 1024 bit size.  Perhaps via the default settings or perhaps in the tutorials and documentation that is read.

Why do operators seem to ignore the input of cryptographers?  I can tell you that from personal experience.  Cryptographers, whenever given a straight question on DNSSEC have failed to give straight answers.  As is evident in the thread, theoretical statements are made and the discussion will veer off into recursive (really cache-protection) behaviors, but never wind up with a result that is clearly presented and defended.  In my personal experience, when I recommended 1024 bits, it was after consulting cryptographic experts who would just waffle on what size is needed and then relying on what we did in workshops 15 years ago.

What does it matter from a security perspective?  DNS messages are short lived.  It’s not like we are encrypting a novel to be kept secret for 100 years.  With zone signing keys lasting a month, 6 months, or so, and the ability to disallow them fairly quickly, what’s the difference between this so-called 80 or 112 bit strength difference?  Yes, I understand the doomsday scenario that someone might “guess” my private key and forge messages.  But an attack is not as simple as forging messages, it takes the ability to inject them too.  That can be done - but chaining all these things together just makes the attack that much less prevalent.

Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because “they could” with the shorted length.  And performance does matter - ask the web browser people.

It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.  DNS operators want smaller, web performance wants quicker.  Putting all that together, the smaller key size makes sense.  In operations.

PS - Yes, some operators do use longer keys.  Generally, those that do have decent “excuses” (read: unusual use cases) and so they are not used in the peer pressure arguments.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Apr 2014 06:44:26 -0700

The profanity is deliberate.  The same discredited performance arguments have come up for a decade+.  It gets very frustrating to see the same ignorance, again and again.

> Why do operators seem to ignore the input of cryptographers?  I can tell you that from personal experience.  Cryptographers, whenever given a straight question on DNSSEC have failed to give straigh…

Well, its because for the most part, cryptographers do seem to understand that DNSSEC is a bit of a joke when it comes to actually securing conventional DNS records.

And the NIST crypto recommendations have existed for years.  1024b RSA was "deprecated in 2010, eliminate completely in 2013".  There may be doubt in NIST now, but 2 years ago, to ignore the standard recommendations is foolish.

> What does it matter from a security perspective?  DNS messages are short lived.  It’s not like we are encrypting a novel to be kept secret for 100 years.  With zone signing keys lasting a month, 6…

Do your resolvers have protection against "roll back the clock" attacks?  If not, you do not "gain protection" from the short-lived (well, really, a few month, they don't roll the actual key every 2 weeks) nature of the ZSK for root, .com, etc.

> Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because “they could” with the shorted length.  And performance does matter - ask the web…

Amdahl's law seems to be something that computer science in general always seems to forget.  The performance impact, both in size and cryptographic overhead, to shift to 2048b keys is negligible in almost all cases.  

And the step function in DNS cost, the "Internet can't do fragments" problem, doesn't really come into play at 2048b.

> It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.  

Yes they have.  2048b.

> DNS operators want smaller, web performance wants quicker.  Putting all that together, the smaller key size makes sense.  In operations.

The real dirty secret.  

DNSSEC is actually useless for, well, DNS.  A records and the like do not benefit from cryptographic protection against a MitM adversary, as that adversary can just as easily attack the final protocol.

Thus the only actual use for DNSSEC is not protecting A records, but protecting cryptographic material and other similar operations: DANE is probably the best example to date, but there is also substantial utility in, e.g., email keys.  

DNSSEC is unique in that it is a PKI with constrained and enforced path of trust along existing business relationships.

Building the root of this foundation on the sand of short keys, keys that we know that are well within range for nation-state adversaries, from the root and TLDs is a recipe to ensure that DNSSEC is, rightly, treated by the rest of the world as a pointless joke.

> PS - Yes, some operators do use longer keys.  Generally, those that do have decent “excuses” (read: unusual use cases) and so they are not used in the peer pressure arguments.

And that does no good unless the upstream in the path of trust, starting at the root, actually use real length keys.

The difference between 2^80 and 2^100 effort is huge.  2^80 is in range today of nation states, and near the range of academics.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 2 Apr 2014 15:47:24 +0200

On Tue, Apr 01, 2014 at 10:37:54PM -0400,
 Olafur Gudmundsson <[email-masked]> wrote 
 a message of 158 lines which said:

> Furthermore using larger keys than your parents is non-sensical as
> that moves the cheap point of key cracking attack.

Mostly true, but still too strong a statement, in my opinion. This is
because, if you are an attacker and managed to crack a key somewhere
between the root (inclusive) and your real target, the higher you are
in the tree, the more things you have to emulate or simulate below. If
you are after ogud.com, and you cracked the root key, you need to
either create a false DS for .com (and then the resolver will croak on
most .com responses, detecting there is something wrong) or a false
NSEC proving that .com is not signed (but the fact that .com is signed
is rapidly cached in validating resolvers).

So, yes, basically, you are right, since DNSSEC is tree-based, the
security of the weakest node is what matters. But, in practice,
exploiting a cracked key upper in the tree is a bit more difficult
than it seems.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 07:04:37 -0700

> Studied != good performance

I believe that there are no elliptic curves that get *much* better verification speeds that P256/P384. Some are a bit faster, but not even close to RSA2048. From your question "Why not go to a good ECC instead", I assumed you were caring about predictability against attacks and key length, which are the strengths of elliptic curve cryptography.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 07:20:02 -0700

On Apr 2, 2014, at 6:44 AM, Nicholas Weaver <[email-masked]> wrote:

> The profanity is deliberate.  

And so is the pushback against it. You may believe that the only way to get the operational change you want in the root zone is to be obnoxious and repetitive; others may believe that you are purposely hurting a cause that they too support.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 2 Apr 2014 11:18:01 -0400

Colleagues,

We've noted the tone some participants in the key length discussion have taken, and the complaints about it. 

We're handling off-list, in accordance with IETF mailing list moderation policy. 

Understood that this is a frustrating topic, but less heat, more light, please.

thanks,
Suzanne & Tim

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 2 Apr 2014 08:26:35 -0700

On Wed, Apr 2, 2014 at 6:30 AM, Edward Lewis <[email-masked]>wrote:

>  One - peer pressure.  Most other operators start out with 1024 bits.  I
> know of some cases where operators wanted to choose other sizes but were
> told to "follow the flock."
>

Cryptographic failures are often undemonstrated for decades. If a state
actor has broken 1024b keys, they're unlikely to advertise that, just use
it now and then as quietly as they can.

Secondly, the application of signatures in DNS and the nature of the DNS
protocol itself presents significant risks that don't make a
straightforward comparison easy.

Suppose your goal is to intercept traffic, and you'd like to cause
www.example.com, a signed domain, to resolve to an IP address that you
control.  Now suppose you also happen to have a /16, not unreasonable for a
large actor - small even. If you can craft a matching signature for
www.example.com with even one of your 2^16 IP addresses, you've succeeded.
You don't have to care which particular IP address you happened to craft a
matching signature for.  This property makes it easier to sieve for
matching signatures.

>From these two main reasons (and you'll notice nothing about cryptographic
> strength in there) a third very import influence must be understood - the
> tools operators use more or less nudge operators to the 1024 bit size.
>  Perhaps via the default settings or perhaps in the tutorials and
> documentation that is read.
>

Do you think that this would be as relevant to the root zone and large TLDs
though?

-- 
Colm

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Apr 2014 11:38:39 -0400 (EDT)

> Well, its because for the most part, cryptographers do seem to understand that DNSSEC is a bit of a joke when it comes to actually securing conventional DNS records.

Funny, the cryptographers I talk to, like at the University of Waterloo,
have always told me our key sizes are giant for the deployment time we
are using them and that we're far above minimum.

> And the NIST crypto recommendations have existed for years.  1024b RSA was "deprecated in 2010, eliminate completely in 2013".  There may be doubt in NIST now, but 2 years ago, to ignore the standa…

I love how people now cherry pick NIST. If it agrees with them they
quote it. If it disagreed with them they shout NSA subverted them.

> Do your resolvers have protection against "roll back the clock" attacks?  If not, you do not "gain protection" from the short-lived (well, really, a few month, they don't roll the actual key every…

Yes, there is a 5011 unbound anchor verification on some of them. And
ntpd doesn't let you jump months in a second either, so only systems
that run ntpdate before ntpd are vulnerable, and only those systems
without a battery backed up clock should do that.

>> Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because “they could” with the shorted length.  And performance does matter - ask the web…

Because we want to make security decisions based on a 1ms latency browser war?

> Amdahl's law seems to be something that computer science in general always seems to forget.  The performance impact, both in size and cryptographic overhead, to shift to 2048b keys is negligible in…

Mind you, I agree we can move to 2048 for ZKSs

> And the step function in DNS cost, the "Internet can't do fragments" problem, doesn't really come into play at 2048b.

I don't think the entire cannot do fragments issue is really still a big
problem. Networks using/depending on 8.8.8.8 has actually cleaned up a
lot of the transport issues involved I think.

>> It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.

Actually my Waterloo cryptographer said you can pick something smaller
than 2048 and larger than 1024 too.

> DNSSEC is actually useless for, well, DNS.  A records and the like do not benefit from cryptographic protection against a MitM adversary, as that adversary can just as easily attack the final proto…

You are mixing in local vs global attacks. For example, Brasil's attack
where the majority of cable modems got their DNS setting changed for
their DHCP server. If hosts were running DNSSEC with using their ISP
as forwarders, this massive attack affecting millions would have
failed. So your statement is rather simplistic and wrong.

> Building the root of this foundation on the sand of short keys, keys that we know that are well within range for nation-state adversaries, from the root and TLDs is a recipe to ensure that DNSSEC i…

Actually, I would LOVE to see a rogue entry signed by the root ZSK. It's
a giant enigma problem if the USG can make these. Please do invite me to
the root-servers meeting following that exposure.

I don't think there is a reason not to switch to 2048 for ZSKs. But I'm
basing that on "there are no significant transport obstacles left".

Paul

---

From: S Moonesamy <[email-masked]>
Date: Wed, 02 Apr 2014 09:06:32 -0700

Hi Ed,
At 06:30 02-04-2014, Edward Lewis wrote:
>  One - peer pressure.  Most other operators start out with 1024 
> bits.  I know of some cases where operators wanted to choose other 
> sizes but were told to "follow the flock."
>
>Two - it works.  No one has ever demonstrated a failure of a 1024 
>bit key to provide as-expected protection.

My short comment would be Yes to the above.

The problem might be the "follow the flock" as there is an assumption 
that someone looked at the details before choosing the 1024 bit key.

>What does it matter from a security perspective?  DNS messages are 
>short lived.  It's not like we are encrypting a novel to be kept 
>secret for 100 years.  With zone signing keys lasting a month, 6 
>months, or so, and the ability to disallow them fairly quickly, 
>what's the difference between this so-called 80 or 112 bit strength 
>difference?  Yes, I understand the doomsday scenario that someone 
>might "guess" my private key and forge messages.  But an attack is 
>not as simple as forging messages, it takes the ability to inject 
>them too.  That can be done - but chaining all these things together 
>just makes the attack that much less prevalent.

For context, the discussion is about a ZSK.  There is a theory that 
it would take under a year and several million (U.S.) dollars to 
break 1024 bits.  It has been said (not on this mailing list) that an 
organization could do it within a shorter time.  It's not a good idea 
to wait for the demonstration as it can raise concerns about the 
entity which chose the key.

As a general comment I tried to find out which NIST recommendations 
are being discussed in respect to DNSSEC.  The requirements mentioned 
by Joe Abley refers to NIST SP 800-78.  That document is about 
"Cryptographic Algorithms and Key Sizes for Personal Identity
Verification".  Is that the NIST recommendation on which this 
discussion is based?

Regards,
S. Moonesamy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 09:17:24 -0700

On Apr 2, 2014, at 8:26 AM, Colm MacCárthaigh <[email-masked]> wrote:

> Cryptographic failures are often undemonstrated for decades. 

This is an important point, particularly when talking about RSA keys. It is important to note that RSA keys are *not* broken by brute force. There is some tricky math that is used to make the problem of finding the private key easier. That math was discovered long after the RSA algorithm was developed. That math kept getting much better for over a decade, but there have been no major public improvements in the math in about a decade. There easily could be non-public improvements that we don't know about; there are certainly a lot of papers that chip away at the problem, albeit slowly for keys >~768 bits.

For elliptic curve cryptography, there was a major improvement that came almost immediately (that's why P256 only has 128 bits of strength), and nothing since then at all. That's why cryptographers think of ECC as more "reliable": there is little expectation that the math will improve for attackers of ECC, and high expectation that it will improve for attackers of RSA and non-EC DSA.

--Paul Hoffman

---

From: "Rose, Scott" <[email-masked]>
Date: Wed, 2 Apr 2014 17:13:31 +0000

On Apr 2, 2014, at 12:06 PM, S Moonesamy <[email-masked]> wrote:

> 
>> What does it matter from a security perspective?  DNS messages are short lived.  It's not like we are encrypting a novel to be kept secret for 100 years.  With zone signing keys lasting a month, 6 months, or so, and the ability to disallow them fairly quickly, what's the difference between this so-called 80 or 112 bit strength difference?  Yes, I understand the doomsday scenario that someone might "guess" my private key and forge messages.  But an attack is not as simple as forging messages, it takes the ability to inject them too.  That can be done - but chaining all these things together just makes the attack that much less prevalent.
> 
> For context, the discussion is about a ZSK.  There is a theory that it would take under a year and several million (U.S.) dollars to break 1024 bits.  It has been said (not on this mailing list) that an organization could do it within a shorter time.  It's not a good idea to wait for the demonstration as it can raise concerns about the entity which chose the key.
> 
> As a general comment I tried to find out which NIST recommendations are being discussed in respect to DNSSEC.  The requirements mentioned by Joe Abley refers to NIST SP 800-78.  That document is about "Cryptographic Algorithms and Key Sizes for Personal Identity
> Verification".  Is that the NIST recommendation on which this discussion is based?
> 

The only DNSSEC related NIST SP's are 800-57 and 800-81-2.  SP 800-57 is in 3 parts, part one is general key considerations and part 3 covers specific uses like DNSSEC.  It's showing its age though.  

The US Federal policy (now) is 2048 bit RSA for all uses, DNSSEC has a special exemption for 1024 bit ZSK's if desired (to reduce risks of fragmented packets).  I do know some .gov zones using 2048 bit KSK and ZSK's as local policies can call for stronger keys.  By 2015, .gov/mil zones should migrate to ECDSA.  Not sure if that will happen given the track record, but that is the roadmap.  

Scott

> S. Moonesamy  

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Apr 2014 08:40:01 +1100

In message <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=[email-masked]>
> least fail open. If CD=0, then SERVFAIL, fail closed.

Guess what, resolvers do not work like that.  They are not required
to work like that.  They are however required to search if CD=0.
SERVFAIL should be a rare event.  SERVFAIL that gets fixed with
CD=1 and then validates successfull should be a even much rarer
event.

We know that there are cases where some of the authoritative servers
broken DNSSEC wise yet you want to optimise for the bad time / trust
anchor in the recursive server.

> --001a11c2a20c040b1504f60880b6
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
> On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <span dir=3D"ltr">&lt;<a href=3D"=
> mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<b=
> r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
> 1px #ccc solid;padding-left:1ex">
> On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:<br>
> &gt; DNSSEC is a mitigation against spoofed responses, man-in-the-middle<br=
> >
> &gt; interception-and-rewriting and cache compromises. These threats are<br=
> >
> &gt; endpoint and path specific, so it&#39;s entirely possible that one of =
> your<br>
> &gt; resolvers (or its path) has been compromised, but not others. If all o=
> f<br>
> &gt; your paths have been compromised, then there is no recovery; only<br>
> &gt; detection. But that is always true for DNSSEC.<br>
> <br>
> Consider the scenario in which one authoritative server for a zone<br>
> has been compromised and the others have not, and that one happens to<br>
> have the lowest round-trip time, so it&#39;s favored by your resolver.=A0</=
> blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
> der-left:1px #ccc solid;padding-left:1ex">
> <br>
> If you query with CD=3D0, a validating resolver detects the problem<br>
> and tries again with another auth server. =A0It doesn&#39;t give up until<b=
> r>
> the whole NS RRset has failed.=A0</blockquote><blockquote class=3D"gmail_qu=
> ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
> ">
> <br>
> If you query with CD=3D1, you get the bogus data and it won&#39;t validate.=
> <br></blockquote><div>=A0</div><div>I don&#39;t think this makes much sense=
>  for a coherent resolver. If I were writing a resolver, the behaviour would=
>  instead be; =A0try really hard to find a valid response, exhaust every rea=
> sonable possibility. If it can&#39;t get a valid response, then if CD=3D1 i=
> t&#39;s ok to pass back the invalid response and its supposed signatures - =
> maybe the stub will no better, at least fail open. If CD=3D0, then SERVFAIL=
> , fail closed.=A0</div>
> <div><br></div><div>Although CD means &quot;checking disabled&quot;, I woul=
> dn&#39;t actually disable checking, simply because that&#39;s stupid (I don=
> &#39;t mean to be impolite, but I don&#39;t have a better word to use here)=
> . But by preserving the on-the-wire semantics of the CD bit, I&#39;d preser=
> ve effectiveness as a cache, and pass on what&#39;s needed to validate even=
>  the failure cases.=A0</div>
> <div><br></div></div><div><br></div>-- <br>Colm
> </div></div>
> 
> --001a11c2a20c040b1504f60880b6--
> 
> 
> --===============8417192190596279555==
> --===============8417192190596279555==--
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 2 Apr 2014 14:56:18 -0700

On Wed, Apr 2, 2014 at 2:40 PM, Mark Andrews <[email-masked]> wrote:

> to work like that.

Nothing can compel any particular resolver to choose a particular
implementation - but I take note of
https://tools.ietf.org/html/rfc6840#section-5.9 and
https://tools.ietf.org/html/rfc6840#appendix-B which recommends it (as a
"SHOULD") and I generally agree with the good reasoning that's in the RFC.

As I wrote, if it were me writing a validating stub resolver, I would
always set CD=1 - and when acting as an intermediate resolver, I would
always make a reasonable effort to find a validating response, even if CD=0
is on the incoming query. I'm certain that at least one resolver does work
like this, and I suspect it's also how Google Public DNS works, based on
some experimentation.

-- 
Colm

---

From: S Moonesamy <[email-masked]>
Date: Wed, 02 Apr 2014 14:46:01 -0700

Hi Scott,
At 10:13 02-04-2014, Rose, Scott wrote:
>The only DNSSEC related NIST SP's are 800-57 and 800-81-2.  SP 
>800-57 is in 3 parts, part one is general key considerations and 
>part 3 covers specific uses like DNSSEC.  It's showing its age though.
>
>The US Federal policy (now) is 2048 bit RSA for all uses, DNSSEC has 
>a special exemption for 1024 bit ZSK's if desired (to reduce risks 
>of fragmented packets).  I do know some .gov zones using 2048 bit 
>KSK and ZSK's as local policies can call for stronger keys.  By 
>2015, .gov/mil zones should migrate to ECDSA.  Not sure if that will 
>happen given the track record, but that is the roadmap.

Thanks for the above information.  Adding to it, 1024-bit RSA keys 
are allowed until 2015.  There is an explanation about that 
recommendation, i.e. it's not only about packet size.

Regards,
S. Moonesamy

---

From: David Conrad <[email-masked]>
Date: Thu, 3 Apr 2014 12:18:06 +0900

Paul,

> Because we want to make security decisions based on a 1ms latency browser war?

We want to make security decisions that actually improve security.

Making a decision that results in people turning security off because the (perceived at least) performance impact is too large does not improve security.

People are already doing insanely stupid things (e.g., not following TTLs) because they eke out a couple of extra milliseconds in reduced RTT per query (which, multiplied by the zillions of queries today's high content websites require, does actually make a difference).

Having not looked into it sufficiently, I do not have a strong opinion as to whether increasing key lengths will result in people either not signing or turning off validation, but I believe it wrong to disregard performance considerations.

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Apr 2014 00:07:36 -0400 (EDT)

> Making a decision that results in people turning security off because the (perceived at least) performance impact is too large does not improve security.

I'm happy to hear the browser vendors taking DNS latency seriously, and
look forward to their contributions towards solving that, with solutions
such as http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query/

Perhaps they will even advise running resolvers on the stubs with
pre-fetching of low TTL records so they can get out of the DNS caching
business themselves.

> People are already doing insanely stupid things (e.g., not following TTLs) because they eke out a couple of extra milliseconds in reduced RTT per query (which, multiplied by the zillions of queries…

Luckily, I think we've seen the chrome/speed pendulum is already
swinging back, and the browser vendors are seeing that users do
care about more than just about latency.

> Having not looked into it sufficiently, I do not have a strong opinion as to whether increasing key lengths will result in people either not signing or turning off validation, but I believe it wron…

My previous email explained why I believe those performance considerations
were wrong.  I am not disregarding those out of principle, I'm disregarding
because I don't agree with the reasons offered. Big resolvers can add more
hardware without pain. End nodes like phones have plenty of CPU to use
up while waiting for latency, and then some.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Apr 2014 11:14:04 +0100

On 3 April 2014 04:18, David Conrad <[email-masked]> wrote:
>>>> Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because "they could" with the shorted length.  And performance does matter - ask the web browser people.

Before that question even becomes relevant, DNSSEC has to actually get
to the endpoints reliably, which we know it doesn't. By the time that
happens, the whole question of what key size should be used will
likely have a different answer anyway.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 03 Apr 2014 15:11:44 +0200

>  signature than 2048 bit RSA key. 

=> I got a different figure (6x) for my ECC paper, and:
 - it was published the 3 may 2013 so one can expect ECC performance
  has been improved since I got it

 - P256 ECDSA is stronger than 2048 bit RSA so it is like comparing
  oranges and grapefruits.

BTW if signing is faster than verifying it is not an ECC property
but an (EC)DSA one.

Regards

[email-masked]

PS: to come back to the 1024 vs 2048 discussion: 1024 bit RSA is weaker
than some might want but there is (and will be in a reasonable time
frame) no practical attack against it. In fact I am more concerned
by possible (?) attacks against a rollover chain...