Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-01.txt
On Tue, Dec 18, 2018 at 11:30 AM Sara Dickinson wrote: > Hi All, > > We’ve just published an update to the draft with the following updates: > > * Update DoH reference to RFC8484 and add more text on DoH > * Split threat descriptions into ones directly referencing RFC6973 and > other DNS Privacy threats > * Improve threat descriptions throughout > * Remove reference to the DNSSEC TLS Chain Extension draft until new > version submitted. > * Clarify use of whitelisting for ECS > * Re-structure the DPPPS, add Result filtering section. > * Remove the direct inclusion of privacy policy comparison, now just > reference dnsprivacy.org and an example of such work. > * Add an appendix briefly discussing DNSSEC > * Many minor editorial fixes > * Update affiliation of 1 author > > At the mic line at the last IETF meeting where this was discussed (IETF > 102) there was support for both splitting this document up into 2 or more > documents and also keeping everything in a single document. For ease of > review at this point we have not changed the structure but would appreciate > comments about this on the list. > > Best regards > > Sara. > > > On 18 Dec 2018, at 16:28, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the DNS PRIVate Exchange WG of the IETF. > > > >Title : Recommendations for DNS Privacy Service > Operators > >Authors : Sara Dickinson > > Benno J. Overeinder > > Roland M. van Rijswijk-Deij > > Allison Mankin > > Filename: draft-ietf-dprive-bcp-op-01.txt > > Pages : 33 > > Date: 2018-12-18 > > > > Abstract: > > This document presents operational, policy and security > > considerations for DNS operators who choose to offer DNS Privacy > > services. With these recommendations, the operator can make > > deliberate decisions regarding which services to provide, and how the > > decisions and alternatives impact the privacy of users. > > > > This document also presents a framework to assist writers of DNS > > Privacy Policy and Practices Statements (analogous to DNS Security > > Extensions (DNSSEC) Policies and DNSSEC Practice Statements described > > in [RFC6841]). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-01 > > Minor nits: 5.1.5. Service options DNS Privacy Threats: o Unfairly disadvantaging users of the privacy service with respect to the services available. This could force the user to switch to the services available. providers, fallback to cleartext or accept no DNS service for the outage. "the services available. providers," -> "the available service providers," 5.2.1. Data Handling Other Treats "Treats" -> "Threats" -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-01.txt
Hi All, We’ve just published an update to the draft with the following updates: * Update DoH reference to RFC8484 and add more text on DoH * Split threat descriptions into ones directly referencing RFC6973 and other DNS Privacy threats * Improve threat descriptions throughout * Remove reference to the DNSSEC TLS Chain Extension draft until new version submitted. * Clarify use of whitelisting for ECS * Re-structure the DPPPS, add Result filtering section. * Remove the direct inclusion of privacy policy comparison, now just reference dnsprivacy.org and an example of such work. * Add an appendix briefly discussing DNSSEC * Many minor editorial fixes * Update affiliation of 1 author At the mic line at the last IETF meeting where this was discussed (IETF 102) there was support for both splitting this document up into 2 or more documents and also keeping everything in a single document. For ease of review at this point we have not changed the structure but would appreciate comments about this on the list. Best regards Sara. > On 18 Dec 2018, at 16:28, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS PRIVate Exchange WG of the IETF. > >Title : Recommendations for DNS Privacy Service Operators >Authors : Sara Dickinson > Benno J. Overeinder > Roland M. van Rijswijk-Deij > Allison Mankin > Filename: draft-ietf-dprive-bcp-op-01.txt > Pages : 33 > Date: 2018-12-18 > > Abstract: > This document presents operational, policy and security > considerations for DNS operators who choose to offer DNS Privacy > services. With these recommendations, the operator can make > deliberate decisions regarding which services to provide, and how the > decisions and alternatives impact the privacy of users. > > This document also presents a framework to assist writers of DNS > Privacy Policy and Practices Statements (analogous to DNS Security > Extensions (DNSSEC) Policies and DNSSEC Practice Statements described > in [RFC6841]). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS PRIVate Exchange WG of the IETF. Title : Recommendations for DNS Privacy Service Operators Authors : Sara Dickinson Benno J. Overeinder Roland M. van Rijswijk-Deij Allison Mankin Filename: draft-ietf-dprive-bcp-op-01.txt Pages : 33 Date: 2018-12-18 Abstract: This document presents operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, and how the decisions and alternatives impact the privacy of users. This document also presents a framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-01 https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Warren Kumari writes: > 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". my situation: 7: "Hey Wes, how's things? Yeah, I know we supported everything for you in the past because you're smart, we're smart and we're small enough to pretty much help everyone. But to get you the speed you wanted, we had to outsource your connection and address space to and they won't let us do reverse DNS for you even though you're static. Sorry." -- 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
Wes Hardaker wrote: > > 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 Reverse zones plural (v4 + v6) :-) > - 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. For forward DNS it is 1 per name server name (i.e. per alias), which might be 1 per zone for places that provision zones with in in-bailiwick name server names, or might be 1 per server if they prefer to provision zones with canonical name server names. > - 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 The "more lookups" thing is interesting. If the TLSA-like record is in the forward DNS, then you get into a bootstrapping problem. Assuming we can't add these new records as glue, a resolver ends up having to: * query a parent server for delegation; receive NS records and glue * query a child server publicly for TLSA-like record(s) * query child server privately for actual question i.e. in the DNS case we lose the opportunity for concurrent address + TLSA queries that DANE normally offers. If the TLSA-like record is in the reverse DNS, and the reverse DNS nameservers are cached, then the sequence of lookups is the same. The "more lookups" case happens when there's a cold reverse DNS cache as well as a cold forward cache. Putting TLSA-like records in the reverse DNS doesn't solve the bootstrap problem, in cases where the server you want the TLSA-like record for is authoritative for its own reverse zones. I started a thread discussing related things back in September... https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html Tony. -- f.anthony.n.finchhttp://dotat.at/ public services available on equal terms to all ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
