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

[Paul Hoffman <[e-mail]>]

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:
> 
> On Wed, 2020-11-04 at 15:04 +0000, Paul Hoffman wrote:
>> It would be useful if a resolver could tell in advance, and at a cost less than port-checking. There could be a new protocols developed to do that. I don't see this as a requirement, though, given the low cost of port-checking.
> 
> 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.

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

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

> 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. This is why I think we should compare the result to port-checking.

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.

--Paul Hoffman