Re: [DNSOP] Current DNSOP thread and why 1024 bits

[Paul Wouters <[e-mail]>]

On Thu, 3 Apr 2014, David Conrad wrote:

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

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 today's high content websites require, does actually make a difference).

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 wrong to disregard performance considerations.

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