Re: [DNSOP] [dns-privacy] draft-mayrhofer-edns0-padding
On Thu 2015-07-23 18:50:14 +0200, Alexander Mayrhofer wrote: I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as artificial RRs in the additional section), and I floated the idea that we could use EDNS0 to include padding in DNS packets. So, I've created a quick-and-dirty strawman proposal draft for this idea, and i'm happy to discuss this during tomorrow's DPRIVE session if we have time: https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt wow, thanks for the incredibly quick writeup! I think this draft could have an informative reference to Haya Shulman's research on difficulties in DNS encryption, which won the recent ANRP: https://irtf.org/anrp https://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf Section 3.2.2 shows that her mechanism for inferring the contents of queries becomes *even more effective* by including the size of the packets in her analysis. (Everyone working on dprive should read this paper to get a sense of some of the massive difficulties we need to consider because of the structure of DNS traffic analysis; just encrypting the traffic is insufficient for several reasons) I also note that draft-mayrhofer-edns0-padding curently suggests that the minimum padding size is 1 octet. Is there any reason to avoid a padding size of 0? --dkg ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] draft-mayrhofer-edns0-padding
This can be dropped. EDNS aware clients are required to ignore unknown EDNS options. A server MUST use the 'Padding' option in a DNS response (QR=1) only when that response correlates to a query that contained the 'Padding' option. For QUERY I would be padding the request out to 400 octets. This allows for all legal query names (max question size is 255+2+2 octets), some EDNS options and the pad option. Mark In message 87a8umihra@alice.fifthhorseman.net, Daniel Kahn Gillmor writes: On Thu 2015-07-23 18:50:14 +0200, Alexander Mayrhofer wrote: I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as artificial RRs in the additional section), and I floated the idea that we could use EDNS0 to include padding in DNS packets. So, I've created a quick-and-dirty strawman proposal draft for this idea, and i'm happy to discuss this during tomorrow's DPRIVE session if we have time: https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt wow, thanks for the incredibly quick writeup! I think this draft could have an informative reference to Haya Shulman's research on difficulties in DNS encryption, which won the recent ANRP: https://irtf.org/anrp https://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf Section 3.2.2 shows that her mechanism for inferring the contents of queries becomes *even more effective* by including the size of the packets in her analysis. (Everyone working on dprive should read this paper to get a sense of some of the massive difficulties we need to consider because of the structure of DNS traffic analysis; just encrypting the traffic is insufficient for several reasons) I also note that draft-mayrhofer-edns0-padding curently suggests that the minimum padding size is 1 octet. Is there any reason to avoid a padding size of 0? --dkg ___ 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] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
--On Monday, July 20, 2015 13:50 -0400 Bob Harold rharo...@umich.edu wrote: This thread has taught me more about the .onion names - thanks for that. But I would have to agree with those that think this bit of explanation is unnecessary to the RFC and should be excluded, rather than attempting to clarify it. The RFC only needs to deal with .onion. No need to explain the other parts of the name. FWIW, I tend to agree. If the purpose of the document is to try to lock down the name, it should explain what ONION. is and how it is deployed to the extent needed to justify that and incorporate explanations of how the hierarchical structure is used and accessed, as well as the nature of the protocol itself, by reference if at all.If the intent is to incorporate and/or explain the latter, how TOR works, etc., that is a rather different sort of document. The latter might still try to reserve the top-level name as an IANA Considerations effect, but is one over which the IETF would typically want change control as a condition for IETF Stream publication. john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-mayrhofer-edns0-padding
What does it mean to exceed the proffered EDNS0 buffer size with your padded response? You're 'silent' on length, but surely the server should respect the EDNS0 size proffer as a limit? On Thu, Jul 23, 2015 at 6:50 PM, Alexander Mayrhofer alexander.mayrho...@nic.at wrote: Hi, I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as artificial RRs in the additional section), and I floated the idea that we could use EDNS0 to include padding in DNS packets. So, I've created a quick-and-dirty strawman proposal draft for this idea, and i'm happy to discuss this during tomorrow's DPRIVE session if we have time: https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt Bring out the pitchforks and torches :) Alex ___ 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] draft-mayrhofer-edns0-padding
George, i certainly agree. Noted for a revision. Alex Von: George Michaelson [mailto:g...@algebras.org] Gesendet: Donnerstag, 23. Juli 2015 18:52 An: Alexander Mayrhofer Cc: dns-priv...@ietf.org; dnsop@ietf.org Betreff: Re: [DNSOP] draft-mayrhofer-edns0-padding What does it mean to exceed the proffered EDNS0 buffer size with your padded response? You're 'silent' on length, but surely the server should respect the EDNS0 size proffer as a limit? On Thu, Jul 23, 2015 at 6:50 PM, Alexander Mayrhofer alexander.mayrho...@nic.atmailto:alexander.mayrho...@nic.at wrote: Hi, I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as artificial RRs in the additional section), and I floated the idea that we could use EDNS0 to include padding in DNS packets. So, I've created a quick-and-dirty strawman proposal draft for this idea, and i'm happy to discuss this during tomorrow's DPRIVE session if we have time: https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt Bring out the pitchforks and torches :) Alex ___ DNSOP mailing list DNSOP@ietf.orgmailto:DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Draft copy of the minutes
Hi I've upload the draft version of the minutes from the meeting on Monday. Big thanks to Paul Hoffman for putting these together. When you have a minute,take a look and let us know if there are any corrections. https://www.ietf.org/proceedings/93/minutes/minutes-93-dnsop thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
On Thu, Jul 23, 2015 at 6:46 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Thu, Jul 23, 2015 at 12:50:37PM +0800, 延志伟 yanzhi...@cnnic.cn wrote a message of 113 lines which said: #Z. W. Yan: we will revised it as: an authoritative name server #operator can ensure that the recursive server that the client is #using has all the answers in its cache from the authoritative point #of view. Sorry, but it is false, for the reasons explained in my first message. You cannot ensure that. Yah, true. The recursive server is free to not accept responses, to evict cache entries early, to gulp stretch TTL, etc. An authoritative name server can provide information so that the recursive server that the client is using can populate its cache if wants to...? W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-mayrhofer-edns0-padding
Hi, I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as artificial RRs in the additional section), and I floated the idea that we could use EDNS0 to include padding in DNS packets. So, I've created a quick-and-dirty strawman proposal draft for this idea, and i'm happy to discuss this during tomorrow's DPRIVE session if we have time: https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt Bring out the pitchforks and torches :) Alex ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
On Thu, Jul 23, 2015 at 12:50:37PM +0800, 延志伟 yanzhi...@cnnic.cn wrote a message of 113 lines which said: #Z. W. Yan: we will revised it as: an authoritative name server #operator can ensure that the recursive server that the client is #using has all the answers in its cache from the authoritative point #of view. Sorry, but it is false, for the reasons explained in my first message. You cannot ensure that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
