Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN

["Martin Thomson" <[e-mail]>]

Ted,

On Sat, Dec 14, 2019, at 01:43, Ted Hardie wrote:
> On Fri, Dec 13, 2019 at 2:12 PM Erik Nygren <[e-mail]>
> > Linking ALPN and port defeats the purpose of ALPN. 
> 
> Unfortunately, ALPN's native "discovery" mechanism is more-or-less 
> connect and see what the list is. That's pretty much what the original 
> respondents are trying to avoid. 

I think that you are conflating the protocol negotiation with discovery.  ALPN is a negotiation method, and what we are looking for here is discovery.  ALPN allows client and server to negotiate DoT and then be confident that the resulting connection truly is DoT.  ALPN might be useful in identifying a protocol, but we shouldn't be loading ALPN with other semantics as you propose.

The first question we are trying to answer with discovery is "does the network provide a DoT resolver?"  (The next question being "Where is it?"; a question that is at least partially answered by existing methods.)  You answer that by say "I have DoT" or "I have DoT *at this location*".  ALPN only factors into that process to the extent that you need to have some way to distinguish different protocols.  Erik points out that using ALPN as a component of the key tuple is potentially a valuable way of using it.  I agree.

There's a related question here about how the server is then authenticated.  RFC 8310 is far too permissive in its definition of options to be of much use here.  For me, that's a far more interesting question than the one you pose.
 
> So, let's back up a step: are people interested in using DHCP and RA as 
> part of the discovery story here or not?

I am.

I tend to think that https://thpts.github.io/draft-peterson-dot-dhcp/draft-peterson-dot-dhcp.html is a reasonable start here.  Sure, it makes some assumptions, and leaves some of the harder 8310-style questions unanswered, but that's where I think we should be paying more attention anyway.