* Paul Vixie [7/5/2014 5:04 AM]: > 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.
DTLS works on top of UDP (among others) and thus can pass CPE devices. > 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. Could you elaborate on why RFC 1035 prohibits persistent connections? My reading of Section 4.2.2 is that persistent connections are supported: - Servers should keep TCP connections open after transactions. - Clients can keep connections open, if they want to. - The minimum idle time before closing a persistent connection on server-side is 2 minutes. There is no maximum. > 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. I don't see the need to use HTTP. Middleboxes cannot look into TLS traffic, so they will pass DNS-over-TLS like they pass HTTP-over-TLS. > 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). Does JSON have an advantage over binary DNS? > in summary, i agree that we have a narrowly defined problem of on-path > surveillance of dns questions by third parties, but i do not think it > can be solved by further EDNS extensions to UDP/53, and i know it cannot > be handled by using or redefining TCP/53. i have identified a way > forward that relies on TCP/443, noting that other groups are already > repairing SSL to add perfect forward secrecy and to solve the > "government-controlled X.509 CA" problems, and that we can leverage that > work. i've suggested that we specifically focus on the bortzmeyer > solution involving RESTful queries and JSON responses, or perhaps > RESTful URI's using POST of JSON, and JSON responses. Let's sum up the list of possible protocols: - DNS over DTLS over UDP - DNS over TLS over TCP - JSON over HTTP over TLS over TCP Also proposed elsewhere: - DNS over DNSCrypt over UDP/TCP So far I don't see the benefit of JSON and HTTP. Anyway, thanks for framing the problem. Regards, Matt
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
