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

[Mark Andrews <[e-mail]>]

In message <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=[e-mail]>
, Phillip Hallam-Baker writes:
> 
> On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
> <[e-mail]>wrote:
> 
> >
> > On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson <[e-mail]> wrote:
> > >
> > > 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.
> >
> > 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.
> >
> 
> 
> 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.

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.

> So they resisted the idea of an authenticated Stub-client <-> Resolver
> 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.

> Weakening the crypto algorithms to make the architecture work is always a
> sign that the wrong architecture is being applied.
> 
> -- 
> Website: http://hallambaker.com/
> 
> --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:[e-mail]" 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">[e-mail]</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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============8670379042506024621==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]