[DNSOP] DNS over DTLS (DNSoD)
For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls -d ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
TLS seems like a poor choice for any new cryptographic transport, it is a very complicated protocol with a considerable amount of implementation complexity, computational and network costs. DTLS seems poorer still, as it is an adaptation of primitives never intended for datagram transmission. But feedback on the draft: * It's unclear how your protocol would really mitigate an active attacker sending bogus responses. Won't the attacker still be able to disrupt the DTLS session? Allowing session multiplexing by query-id likely amplifies this risk. * In DTLS, the ClientHello is in the plain - this presents opportunities for downgrade attacks and inference making. Considering the proposal advocates for hardcoding the certificate, why not just use a key from the off? * Some nameservers definitely don't just not respond when they get messages they don't understand :/ * Is the entire protocol subject to the simplest downgrade attack of all? Just cause the first server response to be dropped and regular DNS will be used? * How long should session state persist? * The network costs of certificate transmission probably pale in comparison to the computational costs of key negotiation. How should trivial key-exchange ddos attacks be prevented? * TLS Heartbeat messages do not permit asymmetric MTU discovery. On Wed, Apr 23, 2014 at 6:47 AM, Dan Wing d...@danwing.org wrote: For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls -d ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
On Apr 23, 2014, at 7:26 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Apr 23, 2014, at 6:47 AM, Dan Wing d...@danwing.org wrote: For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls This proposes to run a binary protocol (DTLS) over port 53. It says A DNS client or server that does not implement this specification will not respond to the incoming DTLS packets because they don't parse as DNS packets (the DNS Opcode would be 15, which is undefined). Has anyone run any tests against currently deployed recursive resolvers and authoritative servers to see what they do when sent the initial DTLS packet? Paul, openssl s_client -dtls1 -connect 1.2.3.4:53 -debug substituting 1.2.3.4 for the server you want to test, and in another window do tcpdump port 53. -d ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
On Apr 23, 2014, at 8:42 AM, Dan Wing dw...@cisco.com wrote: On Apr 23, 2014, at 7:26 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Apr 23, 2014, at 6:47 AM, Dan Wing d...@danwing.org wrote: For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls This proposes to run a binary protocol (DTLS) over port 53. It says A DNS client or server that does not implement this specification will not respond to the incoming DTLS packets because they don't parse as DNS packets (the DNS Opcode would be 15, which is undefined). Has anyone run any tests against currently deployed recursive resolvers and authoritative servers to see what they do when sent the initial DTLS packet? Paul, openssl s_client -dtls1 -connect 1.2.3.4:53 -debug substituting 1.2.3.4 for the server you want to test, and in another window do tcpdump port 53. Sure. What were the results of your testing? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
On Apr 23, 2014, at 6:47 AM, Dan Wing d...@danwing.org wrote: For discussion. DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls a: With the need to do all the handshaking, you gain only a little from doing dTLS over UDP rather than TLS over TCP. So why use UDP with all its headaches? Just use TCP and conventional TLS rather than DTLS, especially when you are talking about mucking with the handshake. b: DO NOT USE PORT 53 for this: There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS over DNS. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance
The Child may also remove old keys, but this document does not support removing all keys. When the Parent DS is in-sync with the CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the CDS / CDNSKEY record(s); Read the whole thing a couple of times and it's not clear to me how to remove one or more DS? Once in-sync, If the parental agent polling/mechanism detect a CDS for an existing DS, or a CDNSKEY for a matching DS, then you remove the DS but not if it's the last one? Right? Or there's a ADD/DELETE parameter to the proposed CDS and CDNSKEY resource records to instruct the parental agent on the type of operation to perform? Jack -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley Sent: April-21-14 9:34 AM To: Warren Kumari Cc: dnsop; Paul Hoffman Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop- delegation-trust-maintainance On 16 Apr 2014, at 8:02, Warren Kumari war...@kumari.net wrote: I think I made it even clearer: The first time a DNS operator signs a zone, they need to communicate the keying material to their parent through some out-of-band method to complete the chain of trust. Depending on the desires of the parent, the child might send their DNSKEY record, a DS record, or both. I don't think you mean the first time a DNS operator signs a zone. You're making an assumption that a zone, once signed, will never be unsigned. In fact, a zone can be signed, then unsigned, any number of times. Whenever a zone's insecure delegation is replaced by a secure delegation, the DNS operator needs to communicate the keying material... Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. DTLS does not solve any of the problems described at https://queue.acm.org/detail.cfm?id=2578510. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
On Wed, 23 Apr 2014, Nicholas Weaver wrote: b: DO NOT USE PORT 53 for this: There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS over DNS. Yes, I fully agree with this. It was a major objection for me to CurveDNS as well No, I fully disagree with this. Port 53 TCP has a much better chance at working these days than a random other newly assigned port. I'll go get a comfort coffee now. Paul ps. leaning towards custom crypto that fits in DNS formats ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
On Apr 23, 2014, at 1:00 PM, Paul Wouters p...@nohats.ca wrote: No, I fully disagree with this. Port 53 TCP has a much better chance at working these days than a random other newly assigned port. Not true. Port 53 is far more molested than random: INBOUND firewall rules prevent you from running new services without firewall rule modifications, but outbound blocking is far less common. (Our test port for this is TCP 1947 with Netalyzr). -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
I agree that DTLS does not solve any problems for DNS. The basic problem is that DTLS is still based around the notion of a session where the server stores per connection state. So you might as well use TLS for this application. But TLS is not the only option available. Or rather using TLS to secure DNS is not the only option possible. If we use TLS to do a kerberos like key exchange, we can generate a shared secret and a ticket which can then be used to secure all future communications without changing from UDP. We can't run over port 53 (trust me, I tried). But we can nominate the ports to use in the key exchange setup. The resulting protocol works in about 93-98% of network situations (depending on how you measure). So you still need a Web Service backup. But it does work pretty well. On Wed, Apr 23, 2014 at 2:41 PM, Paul Vixie p...@redbarn.org wrote: 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. DTLS does not solve any of the problems described at https://queue.acm.org/detail.cfm?id=2578510. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Website: http://hallambaker.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)
On 23 Apr 2014, at 18:32, Phillip Hallam-Baker hal...@gmail.com wrote: We can't run over port 53 (trust me, I tried). You have doubts about the approach described in draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I find that draft (and the accompanying t-dns technical report) to be quite compelling. If you have doubts, are you mainly concerned about transactions between recursive and authority servers, or between stub resolvers and recursive servers? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)
On Wed, Apr 23, 2014 at 7:11 PM, Joe Abley jab...@hopcount.ca wrote: On 23 Apr 2014, at 18:32, Phillip Hallam-Baker hal...@gmail.com wrote: We can't run over port 53 (trust me, I tried). You have doubts about the approach described in draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I find that draft (and the accompanying t-dns technical report) to be quite compelling. If you have doubts, are you mainly concerned about transactions between recursive and authority servers, or between stub resolvers and recursive servers? I meant Port 53 UDP. There is just too much middlebox stuff that gets in the way. Port 53 TCP might be viable. -- Website: http://hallambaker.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)
On Wed, 23 Apr 2014, Nicholas Weaver wrote: On Apr 23, 2014, at 1:00 PM, Paul Wouters p...@nohats.ca wrote: No, I fully disagree with this. Port 53 TCP has a much better chance at working these days than a random other newly assigned port. Not true. Port 53 is far more molested than random: INBOUND firewall rules prevent you from running new services without firewall rule modifications, but outbound blocking is far less common. (Our test port for this is TCP 1947 with Netalyzr). Provided you use traditional DNS perhaps? Once you account for roaming around different network, I think you will see port 53 us regularly transparently proxied to a local DNS server. When those see something they don't understand because its not traditional DNS, you'll lose. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)
In message alpine.lfd.2.10.1404232145120.4...@bofh.nohats.ca, Paul Wouters
writes:
On Wed, 23 Apr 2014, Nicholas Weaver wrote:
On Apr 23, 2014, at 1:00 PM, Paul Wouters p...@nohats.ca wrote:
No, I fully disagree with this. Port 53 TCP has a much better chance at
working these days than a random other newly assigned port.
Not true. Port 53 is far more molested than random: INBOUND firewall
rules prevent you from running new services without firewall rule
modifications
, but outbound blocking is far less common. (Our test port for this is TCP
1947 with Netalyzr).
Provided you use traditional DNS perhaps? Once you account for roaming
around different network, I think you will see port 53 us regularly
transparently proxied to a local DNS server. When those see something
they don't understand because its not traditional DNS, you'll lose.
Paul
Which doesn't handle RD=0 queries and often doesn't handle DNSSEC.
This still isn't a reason to not use port 53. It is a reason to
write Transparent DNS Proxies Considered Harmful.
It is a reason to have a DHCP{v6} option for hotspot registration.
Mark
___
dns-privacy mailing list
dns-priv...@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance
Hi Jacques, On 04/23/2014 06:57 PM, Jacques Latour wrote: The Child may also remove old keys, but this document does not support removing all keys. When the Parent DS is in-sync with the CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the CDS / CDNSKEY record(s); Read the whole thing a couple of times and it's not clear to me how to remove one or more DS? Once in-sync, If the parental agent By removing the corresponding CDS/CDNSKEY from the CDS/CDNSKEY RRset. polling/mechanism detect a CDS for an existing DS, or a CDNSKEY for a matching DS, then you remove the DS but not if it's the last one? No: The parent would never remove a DS when it sees a CDS/CDNSKEY for an existing DS. Right? Or there's a ADD/DELETE parameter to the proposed CDS and CDNSKEY resource records to instruct the parental agent on the type of operation to perform? Let me try to rephrase: The child can signal its desire to add DS records by publishing corresponding records in the CDS/CDNSKEY RRset. The child can also signal its desire to remove DS records by removing the corresponding records from the CDS/CDNSKEY RRset again. If the CDS/CDNSKEY RRset is in-sync with the DS RRset at the parent, the child MAY remove the CDS/CDNSKEY RRset from its zone. If the parent sees no CDS/CDNSKEY RRset published in the child's zone, this means there is no action to perform for the parent. Hence, this document does not support removing all DS records from the parent. Best regards, Matthijs Jack -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley Sent: April-21-14 9:34 AM To: Warren Kumari Cc: dnsop; Paul Hoffman Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop- delegation-trust-maintainance On 16 Apr 2014, at 8:02, Warren Kumari war...@kumari.net wrote: I think I made it even clearer: The first time a DNS operator signs a zone, they need to communicate the keying material to their parent through some out-of-band method to complete the chain of trust. Depending on the desires of the parent, the child might send their DNSKEY record, a DS record, or both. I don't think you mean the first time a DNS operator signs a zone. You're making an assumption that a zone, once signed, will never be unsigned. In fact, a zone can be signed, then unsigned, any number of times. Whenever a zone's insecure delegation is replaced by a secure delegation, the DNS operator needs to communicate the keying material... Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
