Paul,
This seems like a fine and modular approach that doesn't boil the ocean.
Eliot
On 7/5/14, 5:04 AM, Paul Vixie wrote:
i've now seen a number of proposals reaction to the snowden
disclosures, seeking channel encryption for dns transactions. i have
some thoughts on the matter which are not in response to any specific
proposal, but rather, to the problem statement and the context of any
solution.
first, dns data itself is public -- the data is there for anybody to
query for it, if you know what to query for. only the question,
questioner, and time can be kept secret. answers are only worth keeping
secret because they identify the question, questioner, and time.
second, dns transactions are not secret to protocol agents. whether stub
resolver, full resolver, forwarder, proxy, or authority server -- the
full identity of the question must be knowable to the agent in order to
properly process that question. if the agent does logging, then the
question, questioner, and time will be stored and potentially shared or
analyzed.
by implication, then, the remainder of possible problem statement
material is hide question from on-wire surveillance, there being no
way to hide the questioner or the time. to further narrow this, the
prospective on-wire surveillance has to be from third parties who are
not also operators of on-path dns protocol agents, because any second
party could be using on-wire surveillance as part of their logging
solution, and by (2) above there is no way to hide from them. so we're
left with hide question from on-wire surveillance by third parties.
this is extremely narrow but i can envision activists and dissidents who
rightly fear for their safety based on this narrowly defined threat, so
i'm ready to agree that there should be some method in DNS of providing
this secrecy. and as we know from the history of secrecy, if you only
encrypt the things you care about, then they stand out. therefore,
secrecy of this kind must become ubiquitous.
datagram level channel secrecy (for example, DTLS or IPSEC) offers a
solution which matches the existing datagram level UDP transport used
primarily by DNS. however, the all-pervasive middleboxes (small plastic
CPE devices installed by the hundreds of millions by DSL and Cable and
other providers) have been shown to be more powerful than IPv6, DNSSEC,
and EDNS -- we could expect them to prevent any new datagram level
channel secrecy protocol we might otherwise wish to employ.
TCP/53 is less prone to middlebox data inspection, and may seem to be an
attractive solution here. i think not for two reasons. first, TCP/53
is often blocked outright, and second, because TCP/53 as defined in RFC
1035 has a connection management scheme that prohibits persistent TCP/53
connections at Internet scale, and we cannot afford the setup/teardown
costs of a non-persistent TCP-based channel secrecy protocol for DNS. to
those who suggest redefining TCP/53 and upgrading the entire physical
plant and all software and operating systems, i challenge you to first
show how this is less global effort than other proposals now on the
table, and then show how you would handle the long-tail problem, since
many agents will never be upgraded, or will only be upgraded on a scale
of half-decades. DNS works today because TCP/53 is a fallback for
UDP/53. its definition and deployment makes it unsuitable either
currently or as-would-be upgraded to become the primary transport.
i suggest that any channel secrecy protocol we wish to add to the DNS
system must be suitable as the primary transport, to which the existing
UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any
new transport be operable at internet scale, which demands connection
persistence. finally i suggest that this be done using a protocol that
the internet's middle boxes (cheap CPE devices who think they know
what all valid traffic must look like) will allow to pass without comment.
one candidate for this would be RESTful JSON carried over HTTPS. because
of its extensive use in e-commerce and web API applications, HTTPS
works everywhere. because HTTPS currently depends on X.509 keys, other
groups in the IETF world are already working to make HTTPS proof against
on-path surveillance. (google for perfect forward secrecy to learn
more), and others are working to defend the internet user population
against wildcard or targeted SSL certificates issued by governments and
other anti-secrecy agents with on-path capabilities.
stephane bortzmeyer has already shown us that JSON representation of DNS
transactions is possible. i have heard from another protocol engineer
who is also working in this area (and who credits bortzmeyer for
informing his work).
the special advantage of TCP/443 as a primary transport for persistent
DNS with channel secrecy is that HTTPS's connection management permits
massive scale, as in, a single protocol agent with tens
