On Thu, Sep 21, 2017 at 7:49 AM, Eliot Lear <lear@xxxxxxxxx> wrote:
Hi Christian,
On 9/21/17 9:28 AM, Christian Huitema wrote:
>
> Eliot, it seems that what you are looking for is "configuration" rather
> than "discovery".
Tomato/tomato.
No. They are distinct concepts. What matters here is that there is a distinction, not what we call the concepts.
There are actually three distinct sets of data involved here:
1) Information that allows the client to discover what network address and port to connect to.
2) Additional information that the client needs to know before connecting
3) Additional information that the client needs to know but can wait until after making the connection.
'Discovery' can mean just the first. What interests me is addressing the first two. And that means I have to distinguish between information of types 2 and 3.
[Oh and in a real security protocol discovery is a kimono process and privileged.]
Back in the day, there was this protocol called ws-description or something that was supposed to describe the service, I think the problem was that it tried to do too much. The reason the distinction is important is that information of type 3 will be passed in band when the protocol starts up so it only needs to be on the host. But information of type 2 has to come from the discovery infrastructure (aka the DNS) and that means there has to be some mechanism that is not a human that is keeping the data in the DNS and the information in the host in sync.
OK so what sort of additional information are we talking about?
* What version of the service protocol to use
* The endpoint
* What encoding to use - JSON/XML/JSON-C/CBOR/Protocol Buffers/1.NSA
* What authentication is required.
* Whether to use TLS, some other enhancement or raw TCP
* The TLS root of trust
* The TLS certificate.
* The TLS certificate chain.
So which are which? The way I answer that question for my protocols is to ask 'what do I absolutely need to have before I make contact'. Which means 'what would make me pick a different host or port on a host'. So far those are the only things I put in category 2.
I also distinguish between the Service, that which is described by the DNS node with the SRV record and the Host, that is what is described by the DNS node a particular SRV entry points to.
Right now I plan to define the following attributes:
* Web service endpoint
* Protocol version
* Accepted encoding(s)
* Security enhancement (choice of TLS/1.2, ...)
* Fingerprint of root of trust for cert validation
* ECC Key for encrypting TLS handshake in the future.
So I might well have one host offering a service over JSON only and another host offering JSON, XML and Protocol Buffers.
> Of course, DHCP servers can provide hosts with the
> address of a DNS server. This is a form of discovery.
Right. Same with RAs.
I think we need to be brutal here and just reduce DHCP to the absolute bare minimum. DHCP should be considered 'network bootstrap', nothing more. I want this data from DHCP
* Network DNS prefix
* Initial IP address
* Initial DNS Service (with which to contact the production one)
* Fingerprint used to sign network security policy.
So, if I am in a coffee shop (or the NSA, same thing really), my machine connects to the DHCP, gets those four bits of data and then can do an SRV lookup and connect to a service that gives it the full configuration description the network wants to provide.
Then the machine can decide whether it trusts the network enough to want to connect to it at all. This might well involve a splash screen.
> You mention that in enterprise networks would really like the
> hosts to use the DNS server managed by the enterprise; I understand
> that, but it is a configuration decision. The same hosts, when roaming
> outside the enterprise, may not really want to trust the resolution
> service provided by some random Wi-Fi network.
"Really like" understates the case. It is what happens today, and it is
necessary for the reasons I mentioned previously, specifically but not
limited to, split dns and malware detection and prevention. I'm not
saying that what you're saying above is in any way invalid, but the
other use case is pretty darn serious.
I don't want to prevent that, I want to be able to do it right.
I am willing to give my employer that control when I visit HQ. I am not prepared to give YOUR employer that control and certainly not Panera.
> The issue of configuration is not limited to DoH. The exact same issue
> arises with DNS over DTLS or DNS over DTLS, or even with the rather
> common practice of chosing a DNS service independent of the network,
> such as Google DNS.
The matter has thus far been ducked, and it is time to stop ducking it
+1
> The only difference is that firewalls can easily
> block these other transports, while blocking DNS over HTTPS is harder,
> but even that is debatable. In Prague, DKG demonstrated that you can in
> fact run DNS over TLS on port 443, and defeat most existing firewalls.
From an enterprise administrator perspective that's harmful for reasons
discussed above.
> I
> would argue that the tension between user chosen configuration versus
> network chosen configuration is not specific to DoH, and that it should
> be addressed in either DNSOP or DPRIV.
+1
Proponents should take responsibility for the problems that the new
mechanisms they are standardizing will create. That was the intent of
Security Considerations. Saying it's someone else's problem creates an
externality in the form of a massive DOS attack on others. On the other
hand, you raise an interesting question: why shouldn't the DoH draft go
into DPRIVE such that the discovery problem for both mechanisms could be
addressed there? The group is already chartered.
Again, lets wait for the ENAME workshop.