Re: [dns-privacy] DNS over DTLS (DNSoD)
On Wed, Apr 23, 2014 at 09:16:29AM -0700,
Paul Hoffman paul.hoff...@vpnc.org wrote
a message of 39 lines which said:
Sure. What were the results of your testing?
I quickly tested with .FR authoritative name servers and both NSD and
BIND seem to silently ignore the incoming request. No response is seen
coming back.
08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF],
proto UDP (17), length 192)
192.168.1.10.48864 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
[0q] 0/0/0 (164)
08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF],
proto UDP (17), length 192)
192.168.1.10.48864 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
[0q] 0/0/256 ar:
^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain]
08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF],
proto UDP (17), length 192)
192.168.1.10.48864 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
[0q] 0/0/512 ar:
^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain]
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
-Original Message- From: Paul Vixie [mailto:p...@redbarn.org] Sent: Thursday, April 24, 2014 12:11 AM To: Dan Wing Cc: dn...@ietf.org; dns-privacy@ietf.org; Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy) Subject: Re: [DNSOP] DNS over DTLS (DNSoD) for reasons well-spoken up-thread, if we're going to add a dns transport, i'd like it to be RFC 6013 style TCP (in which session context can be compressed and retained after FIN for full-window-size restart, and which permits the query to be bundled into the SYN packet), or at a minimum, SCTP. SCTP has problems with Firewall and NAT traversal, hence WebRTC is using SCTP over DTLS over DNS (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08). DNSoD does not require server-side DTLS state, this is achieved by the server sending ticket to the DTLS client using the mechanism explained in RFC 5077. -Tiru DTLS does not solve any of the problems described at https://queue.acm.org/detail.cfm?id=2578510. vixie ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
On 24 Apr 2014, at 10:53, Phillip Hallam-Baker hal...@gmail.com wrote: If you want to use TLS with DNS then use port 443. One of the effects of firewalls is that we now only have three ports for all protocols: Port 80/UDP: Non SSL traffic Port 443/TCP: SSL traffic Port 53/UDP: DNS I think it's important to frame the problem space. I suspect that the firewall challenges you cite most often apply to communications between stub resolvers and recursive resolvers, for hosts that are using an off-net resolver (directly, or via a proxy). I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many reasons not to do that, and that the network path between ISP resolver and authority servers is very likely to be clean. For ISP, read campus, enterprise, etc as appropriate. I have no science to back up my suspicions, here. Given that others apparently have different suspicions, equally plausible, perhaps science is needed. However, I'll note that the conversations surrounding the problem statement in London all seemed to support separating these two uses of the protocol. I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority servers), which is what t-dns/draft-hzhwm-start-tls-for-dns looks like to me. This compartmentalisation of the problem space reminds me of RFC 4409, and makes me wonder whether there's a way to replace stub-resolver communications with something new without breaking everything. After all, in a very real sense we really only have two edge platforms to worry about (Android and iOS). Joe ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley jab...@hopcount.ca wrote: On 24 Apr 2014, at 10:53, Phillip Hallam-Baker hal...@gmail.com wrote: If you want to use TLS with DNS then use port 443. One of the effects of firewalls is that we now only have three ports for all protocols: Port 80/UDP: Non SSL traffic Port 443/TCP: SSL traffic Port 53/UDP: DNS I think it's important to frame the problem space. I suspect that the firewall challenges you cite most often apply to communications between stub resolvers and recursive resolvers, for hosts that are using an off-net resolver (directly, or via a proxy). I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many reasons not to do that, and that the network path between ISP resolver and authority servers is very likely to be clean. For ISP, read campus, enterprise, etc as appropriate. My interest at the start was censorship prevention so my interest is almost exclusively client-resolver. It does look like a totally different protocol to resolver-authoritative though. Since what we are concerned with here is (also) privacy, I agree that the resolver-authoritative loop is also in play. But that is a vastly lower priority than the client-resolver loop. If you don't solve that, you don't have any solution. The two problems are completely separate from a trust point of view. For key management in the Resolver-Authoritative loop you almost certainly want to use DNSSEC. But in the client-resolver loop you might well want to use WebPKI because you would want accountability. I have no science to back up my suspicions, here. Given that others apparently have different suspicions, equally plausible, perhaps science is needed. However, I'll note that the conversations surrounding the problem statement in London all seemed to support separating these two uses of the protocol. I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority servers), which is what t-dns/draft-hzhwm-start-tls-for-dns looks like to me. You know when people use loaded terms like 'butchering the protocol' to mean 'do it a different way to me' I start to get a little cross. For me the idea of putting TLS traffic over the same port as non TLS traffic without careful attention to how the upgrade is achieved would be 'butchering the protocol'. Changing the port number to one that is known to work is a cleaner approach. -- Website: http://hallambaker.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over DTLS (DNSoD)
On Apr 24, 2014, at 8:39 AM, Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: No, the draft states that the DNS server will send no response. Please refer to section 5 of the draft http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-00#section-5 snip After performing the above steps, the host should determine if the DNS server supports DNSoD by sending a DTLS ClientHello message. A DNS server that does not support DNSoD will not respond to ClientHello messages sent by the client, because they are not valid DNS requests (specifically, the DNS Opcode is invalid). /snip Sorry, you are right, and I had misread that. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
On Thu, 24 Apr 2014 11:32:12 -0400, Phillip Hallam-Baker wrote: ... For me the idea of putting TLS traffic over the same port as non TLS traffic without careful attention to how the upgrade is achieved would be 'butchering the protocol'. Changing the port number to one that is known to work is a cleaner approach. ... Agreed that TLS upgrade must be done carefully. Fortunately we have a number of protocools that have survived a TLS retrofit: IMAP, STMP, POP3, FTP, XMPP, LDAP, NNTP (according to http://en.wikipedia.org/wiki/STARTTLS). Several of these protocols are used over WANs, although I would guess DNS has far more frequent help from transparent middleboxes than they do, so YMMV. I think SMTP is a pretty compelling argument that the World May Not End to do STARTTLS, though. It is true that a new port solves the oh noes, something changed and I, the firewall/middlebox, hate you problem. However, it solves that by by turning it into the oh noes, why should I, the firewall, ever open this new port for you. (As as been pointed out.) It seems like a trade-off about which pain one wants to endure. -John ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
