Re: [dns-privacy] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Peter van Dijk <[e-mail]>]

On Sun, 2020-11-15 at 16:52 +0000, Paul Hoffman wrote:
> Thanks for the response! I hope that there is more list discussion before the WG meeting this week.
> 
> On Nov 15, 2020, at 5:52 AM, Peter van Dijk <[e-mail]> wrote:
> > The cost of port checking is not low.
> 
> We disagree in the general case, because I'm assuming a transport cache that is filled before an actual query is sent. Transport caches would be useful for both opportunistic and authenticated encryption.

That makes sense, but there's a risk of penalizing the 'small domain
owner' here.

> We agree in the specific case of "determine the transport at the time the resolver's user is waiting for an answer".

+1

> > Variant 1: try 853 and 53 in parallel. High code complexity and a high likelihood that the first query to a 'new' auth (where 'new' might be measured in minutes) will be plain text anyway.
> 
> There is no code complexity if you are probing the fill a transport cache. There is definitely the large, classical complexity of asyncy-with-abort for determining when needed.
> 
> > Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is a long time.
> 
> For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate need, there is no way to sanely balance "additional privacy" against "addition latency" in a way that everyone (or even most people) would agree to.

Agreed. It's a big spectrum from DOTPIN (~no additional latency, lots
of privacy, but some serious deployment impediments) to some
interpretation of 'just do TLSA' (lots of additional latency) and any
other proposal is likely to fall somewhere on that spectrum, with some
room to be even worse than TLSA. Anything involving potential timeouts
does look bad from the start, to me.

> > This is not happy eyeballs where both transports (v4 and v6) tend to have identical security properties. 
> 
> Exactly right.
> 
> > DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and guessing in the resolver process. I'd love for us to not add probing and guessing in other parts of that process.
> 
> I would love for that as well, if we make the solution barely harder to implement than port-checking. I am skeptical that we as a group can make a simple solution because everything we as a group do ends up much more complicated than we expected when we started. 

We are terrible people :-)

> This is why I think we should compare the result to port-checking.

It is a useful baseline for comparison, indeed.

> The interesting wrinkle here is that if the solution is DNS-based, it will very likely be faster than port-checking because in most cases the result will come back much faster than any timeout that someone would pick for port-checking. The answer will likely also have much more value than a port check. That gives us (at least) two axes to compare and argue about, so I think it is worth pursuing. Tony's draft has a lot of good comparison thinking in it already.

Yes.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/