Re: [dns-privacy] Use of separate caches for plain and secure transports
On Mon, Dec 17, 2018 at 1:33 PM Warren Kumari wrote: > > > > On Fri, Dec 14, 2018 at 4:05 PM Christopher Wood > wrote: >> >> On Dec 14, 2018, 12:29 PM -0800, Daniel Kahn Gillmor >> , wrote: >> >> On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote: >> >> On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote: >> >> [And, no, we shouldn't go down the road of "privacy requires you disable >> the cache"] >> >> >> Would you mind elaborating on this comment? As you observe, caches are >> harmful to privacy. Refusal to disable the cache in any (?) >> circumstance therefore seems dismissive of user privacy. Perhaps you >> mean turning it off for every query is not a viable path forward? >> >> >> I hope Wes will answer this question on his own, but i wanted to note >> that privacy is not only harmed by caches. it can also be helped by >> caches. >> >> A query for any name will typically radiate *less* information into the >> world if it's answered from a cache, simply because the resolver in >> question doesn't create additional traffic. >> >> In particular, if the cache is already well-populated, and queries are >> padded appropriately, and the name is relatively likely to be in-cache, >> then the only parties that know what was looked up are the client and >> the resolver itself. No authoritative servers or network observers have >> any additional information to distinguish the query from any other >> cache-resolved query handled by the resolver. >> >> So i don't think caching itself offers a clear benefit or harm for >> privacy. One advantage of a resolver is that it effectively acts as a >> mixing/semi-anonymizing agent on behalf of its users. Assuming that the >> resolver itself is not compromised, it can buffer its users from the >> authoritative servers. >> >> >> Yes, of course, thanks for clarifying the other piece of this puzzle! This >> is indeed a benefit. However, I am not convinced this yields a greater net >> benefit than disabling caching. (I am not aware of any such study or >> analysis on this problem.) That said, all of this depends entirely upon the >> threat model, which can vary greatly. > > > If you disable the cache, and can see that there is an (encrypted) input > query and then immediately an (encrypted) output query to 208.80.154.238 > (ns0.wikimedia.org) you know with very high likelihood what input query was > for. Agreed, though I think leaking the origin through the address is an issue regardless of whether the cache is shared or not. > If you have a shared cache, there is a much higher likelihood that the input > query gets answered from cache (especially for higher popularity names) and > so there is no output query to correlate with. Techniques which refresh the > cache before the TTL has expired (al la HAMMER) further thwart correlation > attacks. I agree in principle, yet it seems TTL-based stub cache refresh mechanisms could be implemented regardless of whether or not there's a shared resolver cache. (Please correct me if I misunderstood your point!) In my opinion, tradeoffs made between enabling or disabling caching are not well studied. (Thanks to Wes for sharing a pointer to his paper which scratches the surface of this interesting problem.) We need more work before we understand these tradeoffs and choose the "right" answer. Best, Chris ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Use of separate caches for plain and secure transports
On Fri, Dec 14, 2018 at 4:05 PM Christopher Wood < christopherwoo...@gmail.com> wrote: > On Dec 14, 2018, 12:29 PM -0800, Daniel Kahn Gillmor < > d...@fifthhorseman.net>, wrote: > > On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote: > > On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote: > > [And, no, we shouldn't go down the road of "privacy requires you disable > the cache"] > > > Would you mind elaborating on this comment? As you observe, caches are > harmful to privacy. Refusal to disable the cache in any (?) > circumstance therefore seems dismissive of user privacy. Perhaps you > mean turning it off for every query is not a viable path forward? > > > I hope Wes will answer this question on his own, but i wanted to note > that privacy is not only harmed by caches. it can also be helped by > caches. > > A query for any name will typically radiate *less* information into the > world if it's answered from a cache, simply because the resolver in > question doesn't create additional traffic. > > In particular, if the cache is already well-populated, and queries are > padded appropriately, and the name is relatively likely to be in-cache, > then the only parties that know what was looked up are the client and > the resolver itself. No authoritative servers or network observers have > any additional information to distinguish the query from any other > cache-resolved query handled by the resolver. > > So i don't think caching itself offers a clear benefit or harm for > privacy. One advantage of a resolver is that it effectively acts as a > mixing/semi-anonymizing agent on behalf of its users. Assuming that the > resolver itself is not compromised, it can buffer its users from the > authoritative servers. > > > Yes, of course, thanks for clarifying the other piece of this puzzle! This > is indeed a benefit. However, I am not convinced this yields a greater net > benefit than disabling caching. (I am not aware of any such study or > analysis on this problem.) That said, all of this depends entirely upon the > threat model, which can vary greatly. > If you disable the cache, and can see that there is an (encrypted) input query and then immediately an (encrypted) output query to 208.80.154.238 ( ns0.wikimedia.org) you know with very high likelihood what input query was for. If you have a shared cache, there is a much higher likelihood that the input query gets answered from cache (especially for higher popularity names) and so there is no output query to correlate with. Techniques which refresh the cache before the TTL has expired (al la HAMMER) further thwart correlation attacks. W > > Best, > Chris > > > --dkg > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Mon, Dec 17, 2018 at 2:37 PM Paul Wouters wrote: > On Mon, 17 Dec 2018, Wes Hardaker wrote: > > > cons: > > - not everyone controls their reverse zone easily, especially for those > > that don't hold at least a /24 allocation. Ironically, I fall into > > this camp but still think this is a better solution than a name-based > one. > > - requires more lookups > > Your ISP should support Classless Delegations, RFC 2317 > > https://tools.ietf.org/html/rfc2317 > > I have deployed this successfully. > Is that a "should" or "SHOULD"? 'cos it certainly isn't a MUST :-P I've tried contacting my ISPs over the years, and the responses have been: 1: "OK, click Start, then Shutdown... Now press the power key and and we'll wait for it to boot" 2: "What? Um. Have you tried turning it off and on again?" 3: "What? Huh. Nope, never heard of that." 4: "You are a dynamic customer. We cannot do anything like that for dynamic customers... Sorry, no we don't do static IPs for residential. Oh! You have a static subnet routed to you?! Weird, I didn't know we did that... " 5: "Yes, we have plans to support IPv6 in the future" [no idea what that has to do with anything ] 6: "We don't allow users to run servers, and so there is no need for you to have reserve DNS". Perhaps you've just been lucky and gotten an ISP which sucks less? W > > > - requires the reverse tree for that address be fully signed > > That might be tricker, if your upstream ISP does not believe in DNSSEC > signing. > > Paul > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Mon, 17 Dec 2018, Wes Hardaker wrote: cons: - not everyone controls their reverse zone easily, especially for those that don't hold at least a /24 allocation. Ironically, I fall into this camp but still think this is a better solution than a name-based one. - requires more lookups Your ISP should support Classless Delegations, RFC 2317 https://tools.ietf.org/html/rfc2317 I have deployed this successfully. - requires the reverse tree for that address be fully signed That might be tricker, if your upstream ISP does not believe in DNSSEC signing. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Use of separate caches for plain and secure transports
Daniel Kahn Gillmor writes: > I hope Wes will answer this question on his own Basically, one of the reasons the DNS protocol has been so robust is because of the caching behavior. It greatly reduces traffic, greatly speeds up lookups. Turning off caching would disable much of this critical infrastructure that the DNS was designed with. Recent work has proven that longer TTLs enable zones to survive DDoS attacks because of caching (https://www.isi.edu/~johnh/PAPERS/Moura18a.pdf). Instead, we could maybe cache the delay instead and do something like "if privacy mode is enabled for first query missing the cache for name X, then store [X, delay] for the resolution time. For all future requests up until the first non-privacy protected query for X, force a delay response but respond from the cache". That's kinda messy, but at least may balance the need to keep the cache with privacy. > , but i wanted to note that privacy is not only harmed by caches. it > can also be helped by caches. Yep. I did some experiments around this at the beginning of 2018 for the NDSS DNS privacy workshop. Paper: http://www.isi.edu/~hardaker/papers/2018-02-ndss-analyzing-root-privacy.pdf Youtube 1: https://youtu.be/bSKBRMNQ7s0 Youtube 2: https://youtu.be/9YYH8JFH_bY?t=21m0s -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
"Reed, Jon" writes: > On the call, someone (Wes?) proposed an alternative such as records in > the reverse zones. Yes, I think this solves a number of issues and creates new ones. IE, the list of pros and cons for all solutions includes no item with zero "cons" unfortunately. My list for putting a TLSA or similar record at the reverse zone include: pros: - the authoritative server more likely in control of its reverse zone than all the forward zones its serving - the number of reverse zone records to update on a key change is 1 per ip address. The number of name server NS records to update per key change is 1 per zone supported, which is very very large for some servers [1]. - it feels cleaner cons: - not everyone controls their reverse zone easily, especially for those that don't hold at least a /24 allocation. Ironically, I fall into this camp but still think this is a better solution than a name-based one. - requires more lookups - requires the reverse tree for that address be fully signed And probably more pros and cons I'm not thinking of at the moment. [1]: the latest huge DANE support jump at https://stats.dnssec-tools.org/ is due to a large number of zones suddenly enabling DANE/SMTP on one.com. That shows the scale of some of the larger zone holders. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
Hi Ralf, On 12/17/18 8:01 AM, Ralf Weber wrote: > Moin! > > On 29 Nov 2018, at 21:59, Brian Haberman wrote: >> I believe all virtual interim meetings that use Webex are recorded. We >> will also have minute takers and jabber scribes like in-person meetings. > Ok so it’s a week after the meeting, but I haven’t seen an announcement > of the location of the recordings or the minutes and my search also > didn’t found any. What is the status on these items? There have been > some discussions on list that refer to the call but I’d rather listen to > the recording first before I comment on them. Tim took minutes and is working on them. He was a bit ill before/during the meeting, so I expect that has caused some delays. The plan is to include a link to the audio in the minutes. In the meantime, you can access the raw audio here: https://youtu.be/ww-zA4sdnkw Regards, Brian signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
Moin! On 29 Nov 2018, at 21:59, Brian Haberman wrote: I believe all virtual interim meetings that use Webex are recorded. We will also have minute takers and jabber scribes like in-person meetings. Ok so it’s a week after the meeting, but I haven’t seen an announcement of the location of the recordings or the minutes and my search also didn’t found any. What is the status on these items? There have been some discussions on list that refer to the call but I’d rather listen to the recording first before I comment on them. So long -Ralf —-- Ralf Weber ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Issues with encoding keys in nameserver DNS names
Daniel Kahn Gillmor wrote: > On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote: > > > > 5. Encoding a key as DNS name of a nameserver makes key rotation harder. > >Not impossible, but really much harder. > > i agree that it makes it harder, but i'm not convinced that it is *much* > harder. In my setup, if server keys are in the server name then rotating them requires liaison work over email to humans at 8 other organizations. (And my setup is not big.) If server keys are alongside then it's easy. > But maybe it's worth reviewing what we're hoping to gain from the > keys-in-names approach too: > > a) indication that private queries are expected to work to this > particular resolver > > b) cryptographic identity material > > But what if we cared only about (a) ? could we signal with a > special/magic terminal label just that private queries are expected to > work, without embedding a key there? That could be a useful approach. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: South 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later. Moderate at first in Irish Sea, otherwise rough or very rough, occasionally high except in Irish Sea. Occasional rain. Good, occasionally poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
