Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Ted Hardie <[e-mail]>]

Hi Brian,

On Fri, Nov 1, 2019 at 8:35 AM Brian Dickson <[e-mail]>
wrote:

>
>    1. The operational cost of serving ADoT answers is prohibitive, due to
>    a number of factors:
>       1. Maintaining state, for TCP and for TLS
>
>
>    1. Set-up overhead for TLS
>       2. Ongoing encryption of traffic after set-up, e.g. AES
>       computational cost, vs "copy bytes" (possible with DMA and no CPU)
>
> You do realize that exactly this set of arguments has been used in the
past, to say that web servers would not be able to switch to TLS by
default?  And yet, the queries per second for popular sites served over TLS
keeps going up and up, and the elastic compute and delivery of services
means that similar methods are available at relatively low incremental
costs?

For an authoritative serving a typical zone (an enterprise, a modest web
site, a government agency), none of these incremental costs matter, given
the expected query load.  They matter for TLDs and popular second level
zones like co.uk, and we should care as a result.  But there is no need to
despair.  If you are willing to see DNS data delivery as a standard
application scaling question, rather than as a special case, there are a
lot of tools available already.


>    1. Deployment of ADoT without providing means for managing these costs
>       is highly unlikely to happen
>       2. Developing means to manage ADoT costs (in the standards, and in
>       implementations) is highly non-trivial.
>
> There's a lot of work to crib from, and there are also, bluntly, people
who can sell you this capacity if you don't want to care.


>    1. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
>    (Cheap, easy, fast, choose two, currently zero are available to choose.)
>
> It's our job to make this better. Bold-faced assertions which don't look
at wider contexts aren't much help there, I'm afraid.

regards,

Ted



> Brian
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>