Hi,The issue with this charter I have is that unless you specify one or several usages one can't evaluate or write security considerations or even discuss the actual security properties of the resulting component. Or rather the statement you can do is very limited. And I think the below quote from the charter is quite misleading, even if accurate.
Den 2017-09-15 kl. 17:44, skrev The IESG:
The use of HTTPS provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTPS infrastructure and policy.
So, yes HTTPS will provide two properties. The DNS data provided are from the "entity" given by Server's cert, and it is provided confidentiality and integrity protected between that server and my client. However, without discussing a particular usage of this format, the system security properties and especially what trust I can place in the data as well as what privacy that is provided is unknown.
Just to show how strange this can be lets compare two different usages with quite different properties are present.
1. After having connected to a web site, the web application uses its own servers to resolve the DNS information for resources the client side application needs by submitting those resolve requests to the same origin server. In this case we keep the usage within the same trust domain. The distributed web application uses the mechanism internally with resolvers that it is configured to be trusted. Each web service has its own resolver and the DNS resolution is internal and separated between applications.
2. Using some autoconf setting, the free WIFI access point at Joe's Coffe announces a DNS over HTTPS stub resolver. The only difference from current DHCP DNS server setting is that the communication between the client and resolver at the gateway is that communication is secured, thus preventing active and passive attacks from other entities in the same WIFI/LAN. But otherwise the trust possible in responses from the resolver has not changed. Nor has the privacy aspects in respect to the infrastructure and what happens upstream of the LAN gateway.
I am quite worried that by simply defining a format and not discuss how it will be used, people will lock on to those three words from the charter: "integrity and confidentiality" and think this resolves everything.
Also which "old" use cases that is really intended to cover and by which entities are really not clear. As "new use cases" are ruled out of scope. So, is the browser contacting an recursive resolver without going through OS a new or an OLD use case?
I really want more clarity on what the WG really should do as its first steps and what usage considerations it needs to write!
Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------
<<attachment: smime.p7s>>