Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

[Nicholas Weaver <[e-mail]>]

On Feb 22, 2011, at 9:32 PM, Masataka Ohta wrote:

> Nicholas Weaver wrote:
> 
>> Random reported SSL setups per second are ~1500/s for a commodity
>> 64B processor with 1024B keys.
> 
> I think you are saying 1024b keys.
> 
> That's a lot slower than typical number on TCP connections per
> second, which means computation load dominates.
> 
> Considering the following statement in RFC5507 (April 2009):
> 
>   DNS queries over TCP are not subject
>   to this length limitation, but TCP imposes significantly higher per-
>   query overhead on name servers than UDP.
> 
> dynamic generation is not feasible at all.

That is a statement in the RFC I find a bit of a red herring:  I personally find that the DNS community's fear of computation made sense 15 years ago, but we are in the days where 1U servers are massively powerful (8+ core 1U servers are reasonable) and, more importantly, we understand how to make huge cluster servers that can RELIABLY scale to entire data centers.

Remember, a cluster solution is ONLY needed for those heavily loaded authorities (TLDs, cc-TLDs) which require case insensitivity in non ASCII text, which is not all that many anyway.

An authority that has more like a few hundred base names can just run on a single system, cache all the common cases, and call it good.


>> AND such compute nodes could cache the signatures for
>> common conventions, which means you can't computationally
>> DOS the common cases
> 
> DOS will clear the cache. Worse, multiple layers of labels
> increase the number of common cases exponentially, unless
> you introduce redirection by BNAME.

I disagree:

a)  The cache can be VERY large: a few GB or more of ram per NODE is trivial (after all, its hard to buy nodes with LESS than 8 GB of RAM these days).  That can hold a lot of entries.

b)  You don't evict old but active entries, so the DOS attack can't evict the common cases that you've learned.

As long as the DOS doesn't start up when you start for the first time, you can learn the common cases and make sure they remain cached in the face of a computational DOS.


Yes, DOS is a problem, but you can structure it so a COMPUTE DOS can only affect new queries which is a far smaller problem: The problem space may be near eXpoNenTIAl, but people don't type that way.


>> 2048B signatures are only ~4x harder than 1024B signatures
>> computationally to GENERATE,
> 
> As 2048 is not very large that Karatsuba Multiplication is
> not very effective.
> 
>> but vastly harder to crack using brute force.
> 
> If it were vastly harder we should be using 520b key, if 512b
> key was good enough 15 years ago.

No, we should have ALWAYS been using 2048B RSA keys and 256B symmetric keys and 512B hashes.  

"If your crypto is in danger of brute forcing by anything short of a cubic earth of sci-fi nanotech, use a longer key."  

We failed that earlier on, but there really IS no excuse for that now.  And 2048B keys should still be on the order of ~300 ops/s/node.