There are two sets of issues:
1) Discovery
2) Presentation
I suggest dividing the drafts into two parts and considering these
separately. DNS currently has two transports. The idea that all uses
can be addressed over TCP is currently unproven as far as the majority
of the stakeholders whose action is required for deployment.
Discovery
========
Confidential DNS and TLS for DNS both handle the discovery portion as
an upgrade from regular DNS protocol. This is directly analogous to
the STARTTLS approach introduced in SMTP. As such it has the advantage
of being expeditious and the weakness of being vulnerable to a
downgrade attack.
While there are approaches that can be taken to prevent a downgrade
attack, these have not matured for STARTTLS/SMTP and it is difficult
to see how to apply DNSSEC in this particular case since the starting
point for discovery is an IP address, not a domain name.
It is clear that 'some mechanism' of this sort is required and the one
presented in TLS for DNS is probably as good as can be done in that
situation.
Private DNS takes the approach of introducing a new protocol for Web
Service binding that leverages TLS to establish an authenticated
session key for a Web service specified by DNS name (i.e.
'google.com', not '8.8.8.8'). This approach is designed to address the
use case where a device establishes a 'lifetime binding' with a
particular DNS service for resolution services. Optionally, a binding
may be for a subset of the DNS namespace.
This proposal is a very general Web Service Discovery mechanism
designed to support multiple protocols. The idea being that when a
device is first initialized, it is bound to a collection of services
that it will need. For an embedded device this would be likely {DNS,
ACME, SMTP, Log}, for a user it would likely be {SMTP, XMPP, IMAP,
DNS, OpenID...}
The two schemes adopt different deployment strategies. DNS over TLS
attempts to reduce the size of the ask to the bare minimum. Private
DNS attempts to maximize the Reward while keeping the cost bounded.
Proposal:
* Adopt the Discovery portion of TLS for DNS now with the proviso that
the in-band upgrade mechanism be demonstrated to support additional
presentation transports and establish a registry for declaring such
transports in the usual way.
* Get a fast win with the above approach if possible, while exploring
Discovery mechanism of Private DNS on an experimental basis.
Presentation
==========
DNS over TLS proposes reuse of the existing TLS stack. This has the
advantage of simplicity if a device already has a TLS stack. Otherwise
it is a vast increase in complexity. The main drawback to TLS is the
need for TCP transport. This is an approach many of us remain
skeptical of. And even if the argument can be won inside the group
there is little evidence that it would be accepted outside.
There are several parties that have the technical resources and
infrastructure who could simply roll out TLS over DNS today if they
were convinced of the benefits. With SPDY we had a vendor come to us
with a fait acompli.
Private DNS proposes a simple mechanism currently based on a
pre-established symmetric key and ticket. But the plan was to drop the
CFRG ECC key in as soon as it became available.
Proposal: Adopt the relevant part of DNS over TLS as the TCP based
scheme and Private DNS as the UDP scheme.
Separating the protocol into layers is work but it is the right
approach I believe.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
