Re: [Add] [EXTERNAL] My single use case

[Tommy Jensen <[e-mail]>]

> I think that the difference is important and we will have to work through both paths, if only because the prevalence of forwarders might mean we need two sets of solutions.

Agreed. The challenges a use case faces have nothing to do with its validity, even if it results in no adoption.

>  I don't think that this necessarily depends on the creation of new infrastructure for authentication of servers that don't have IP addresses in the public address space, but it might make that results less usable for you.

My concern is 2) encompasses more use cases than 1). 1) is limited to the use case of joining a network and needing a recommendation. 2) includes other channels of address acquisition such as offline endpoint configuration. I can accept feature parity for 1) which is no authentication. I can possibly accept lower security for 2) when the address came from network advertisement such as DHCP which isn't secure today, but not when it came from endpoint configuration which may be secured.

More simply: 1) includes both server identity and server source, but 2) only includes server property without accounting for server source.

I understand that may be an implementation decision, but I do want to call out a mechanism built to solve 2) generically may have limited usefulness for clients like me who need to use both interpretations of 2). For me, 2) splits into 2a) and 2b) and the line along which I see the bar for authentication changing is 1) and 2a) on one side and 2b) on the other.

I'll try and articulate this in response to Glenn's request for authentication homework.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Martin Thomson <[e-mail]>
Sent: Thursday, September 10, 2020 7:00 PM
To: Tommy Jensen <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [EXTERNAL] [Add] My single use case

On Fri, Sep 11, 2020, at 01:27, Tommy Jensen wrote:
> > As a new device or application, when I join a network that I have no prior relationship with or configuration for, I want to discover the DoT or DoH resolver that corresponds to the Do53 resolver offered by that network
>
> My issue with this scenario is I see "discover a DoT/DoH" server
> differently from "discover a DoT/DoH server that corresponds to the
> Do53 resolver". The former doesn't require authentication to meet
> security parity with Do53 server use today. The latter is a novel
> concept I would prefer to be authenticated. This means for existing TLS
> infra would only be possible for publicly routable IP addresses, a
> subset of the network-offered servers out there.
>
> Is the difference important to you? Would you be fine with the network
> offering the DoT/DoH server in the first place? If not, I just want to
> better understand why not.

Thanks Tommy, that's a good question.

I worded it this way intentionally to allow for both of the interpretations you refer to:

1. What does the network claim is equivalent (DoT/DoH DHCP/RA discovery for example)
2. What does the provided Do53 resolver claim is equivalent (resinfo for example, or maybe just the opportunistic encryption stuff)

As you point out, the latter introduces an extra hop, which might then lead to difficult questions about authentication and what it means to achieve parity.  That's why this is a non-trivial use case to resolve.

I think that the difference is important and we will have to work through both paths, if only because the prevalence of forwarders might mean we need two sets of solutions.  However, it might be that people choose to adopt policies under these different circumstances once we document the properties of the end solutions.

I don't think that this necessarily depends on the creation of new infrastructure for authentication of servers that don't have IP addresses in the public address space, but it might make that results less usable for you.  It all depends on your tolerance for using unauthenticated information.

For instance, Mozilla's TRR program means that we can be more tolerant of failures in discovery, though that requires that we also be tolerant of attacks that aim to make split horizon unavailable, for example.