Re: [dns-privacy] New Version Notification - draft-ietf-dprive-dnsoquic-12.txt
On Wed, Apr 20, 2022 at 4:57 AM wrote: > > A new version (-12) has been submitted for draft-ietf-dprive-dnsoquic: > https://www.ietf.org/archive/id/draft-ietf-dprive-dnsoquic-12.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dnsoquic-12 > > IETF Secretariat. > > Minor nits: In 5.1.1. Draft Version Identification In the example "doq-i00" Where does the "i" come from? I was expecting "doq-00". 5.5. Session Resumption and 0-RTT Next to last paragraph, "errros" -> "errors" 6.3. Address Validation The end of the first paragraph "to a factor 3." -> "to a factor of 3." -- 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-13.txt
On Fri, Jul 10, 2020 at 4:41 AM Sara Dickinson wrote: > Hi, > > This version should address the final comments from the IESG review. > > Sara. > > > On 10 Jul 2020, at 09:38, 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-13.txt > > Pages : 44 > > Date: 2020-07-10 > > > > Abstract: > > This document presents operational, policy, and security > > considerations for DNS recursive resolver 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 non-normative framework to assist > > writers of a Recursive operator Privacy statement (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-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-13 When I try to view the diff, I get the error: "Couldn't retrieve file 2 ( https://www.ietf.org/archive/id/draft-ietf-dprive-bcp-op-13.txt) - got a redirect to ' https://www.ietf.org/archive/id/draft-ietf-dprive-bcp-op-12.txt'.." -- 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-09.txt
On Mon, May 4, 2020 at 10:11 AM 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-09.txt > Pages : 43 > Date: 2020-05-04 > > Abstract: >This document presents operational, policy, and security >considerations for DNS recursive resolver 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 a DNS >Recursive Operator Privacy Statement (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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-09 > > Thanks for the update. Some comments. 7.1.1. Definition of the Trust model "overtime" > "over time" 7.1.2. Trust Model Bootstrapping The whole first paragraph is difficult to parse - it does not seem like complete sentences. 7.2.2. Automated Trust Anchor Check "to to" > "to" But the sentence does not seem complete. -- 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-early-data-00.txt
On Wed, Apr 22, 2020 at 9:41 AM 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 : Using Early Data in DNS over TLS > Author : Alessandro Ghedini > Filename: draft-ietf-dprive-early-data-00.txt > Pages : 6 > Date: 2020-04-22 > > Abstract: >This document illustrates the risks of using TLS 1.3 early data with >DNS over TLS, and specifies behaviors that can be adopted by clients >and servers to reduce those risks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-early-data/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dprive-early-data-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-early-data-00 > > Looks good to me, one nit: 1. Introduction "tecniques" -> "techniques" -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC
On Mon, Jan 20, 2020 at 6:01 PM The IESG wrote: > > The IESG has received a request from the DNS PRIVate Exchange WG (dprive) > to > consider the following document: - 'DNS Privacy Considerations' >as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2020-02-03. Exceptionally, comments > may > be sent to i...@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > >This document describes the privacy issues associated with the use of >the DNS by Internet users. It is intended to be an analysis of the >present situation and does not prescribe solutions. This document >obsoletes RFC 7626. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > Looks good to me. One grammar nit: 3.5.1.4.2. DoH Specific Considerations next to last paragraph "Some implementations have, in fact, chosen restrict the use of" change to: "Some implementations have, in fact, chosen to restrict the use of" -- 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-xfr-over-tls-00.txt
On Mon, Nov 18, 2019 at 9:46 AM 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 : DNS Zone Transfer-over-TLS > Authors : Han Zhang > Pallavi Aras > Willem Toorop > Sara Dickinson > Allison Mankin > Filename: draft-ietf-dprive-xfr-over-tls-00.txt > Pages : 19 > Date: 2019-11-18 > > Abstract: >DNS zone transfers are transmitted in clear text, which gives >attackers the opportunity to collect the content of a zone by >eavesdropping on network connections. The DNS Transaction Signature >(TSIG) mechanism is specified to restrict direct zone transfer to >authorized clients only, but it does not add confidentiality. This >document specifies use of DNS-over-TLS to prevent zone contents >collection via passive monitoring of zone transfers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-00 Looks good to me. Minor changes: 4.3. Data Leakage of NOTIFY and SOA Message Exchanges "Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers leakage RR of this is not discussed in the following sections." "RR of this" -> "of this RR" 6.4. IP Based ACL on the Primary "This is also possible with XoT but it must be noted that as with TCP the implementation of such and ACL cannot be enforced" "and ACL" -> "an ACL" -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On Fri, Nov 8, 2019 at 9:17 PM Paul Wouters wrote: > > On Nov 8, 2019, at 20:13, Brian Dickson > wrote: > > > > > More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which > lumps together information about TLD failures (now very rare), sites with > failures (becoming increasingly uncommon and having smaller impact), and > durations (typically a week or less on average, but again, this is > anecdotal not statistical.) > > > I have on a few occasions explained to the people running this site that > they were wrong to blame dnssec. Some listed events were generic outages > wrongly blamed on dnssec. No corrections were ever made. The side is > extremely subjectively anti-dnssec. > > > > YMMV, of course. But, fear of rampant validation failures is entirely > misplaced at this point. Enough validation is being done, that such > failures need to be considered the responsibility of the signers, not the > validators. > > > Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are > behind dnssec validators that validation failure would lead to a quick > outage notification by tools or humans. > > Paul > Thanks to everyone for the info and recommendations. I need to figure out how to alert on validation failures, and then enable validation. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On Fri, Nov 8, 2019 at 4:37 PM Paul Wouters wrote: > On Wed, 6 Nov 2019, Paul Hoffman wrote: > > > Given that we are (still supposedly) talking about requirements and not > solutions, I would be unhappy with a requirement that prevents a resolver > that is not validating > > Why would a _resolver_ not be validating ? > > I understand the reasons for web applications that do not want to do > validating, though I disagree with those. But for actual DNS resolvers, > running as DNS caching server on either laptop or in an enterprise, I > see no valid reason why it should not be validating at this point. > > > Any protocol we develop for ADoT capability discovery should prevent > downgrade attacks but should also work fine for resolvers that do not > validate. > > I strongly disagree. Resolvers towards Authoritative servers are core > infrastructure, and that core should have no problems using the latest > DNS RFC's. > > Paul > I hate to admit it, and this is a little off topic, but my resolvers are not (yet) validating. Is there a setting that will attempt to validate, and log if it fails, but still answer the users? I hear that there are occasional sites that fail validation, and would like to know what will break if and when I begin to validate. I will also need to monitor the added load on the servers, although I don't expect it to be a problem. I realize that not everyone agrees with this level of caution/fear/lack-of-backbone (I am sure there are other descriptions people would prefer). -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Operating System API support for DNS security policy
On Mon, Aug 19, 2019 at 1:29 PM Tommy Jensen wrote:
> Hey Iain,
>
> Iain> Many applications rely on operating system APIs to access DNS
> services. As native support of DNS over TLS rolls out in to operating
> systems it seems likely that some applications will wish to control the
> security policy that the operating system applies when it performs DNS
> resolution. For example, the application may wish to require that the
> operating system uses an encrypted DNS protocol.
>
> I actually don't see this being necessary. Walking through the
> possibilities:
>
>- If the OS supports DoT and the configured servers support it:
> - OS should be using DoT whether the app requests it or not
>- If the OS supports DoT but the servers don't:
> - App intent isn't helpful (to the same server)
>- If the OS doesn't support it:
> - App intent isn't helpful
>
> I read this differently - the api needs to tell the app whether the OS
does encrypted DNS:
- OS supports DoT and can connect to a DoT resolver
- App uses OS for DNS
- OS does not support DoT
- App connects to a DoT server itself, bypassing the OS (even though
I dislike this, unless the user has agreed)
- OS supports DoT but cannot reach a DoT server
- various choices, we don't need to discuss this now.
--
Bob Harold
>
>
> My view is that the OS should be taking the most secure DNS route it has
> available regardless of app request (after all, think of all the apps which
> won't request DoT but should). In the case where the OS supports DoT but
> isn't using it, that decision is being made in the context of other
> information, such as enterprise configuration, that the app may not have.
>
> Iain> Unless operating systems support secure DNS standards and expose
> APIs to allow applications to use them effectively then applications that
> require secure DNS have little choice other than to roll their own
> implementations.
>
> I totally agree. Platforms should be providing the network tools apps need
> so all apps can benefit similarly, rather than leaving apps to figure out
> networking nuance on their own. I just think in this case that there should
> never have to be a situation where an app needs to request DNS encryption
> (because either it's already happening or it can't happen for some reason
> unknown to the app).
>
> Summary: I think such an API should be unnecessary on well-behaved
> platforms.
>
> Thanks,
> Tommy
> --
> *From:* dns-privacy on behalf of Iain
> Sharp
> *Sent:* Monday, August 19, 2019 2:56 AM
> *To:* dns-privacy@ietf.org
> *Subject:* [dns-privacy] Operating System API support for DNS security
> policy
>
>
> All,
>
>
>
> DNS over TLS offers the ability to perform DNS queries over a TLS secured
> channel. In my understanding, DNS over TLS is not yet available in all
> operating systems, but operating system support could become common in
> future.
>
>
>
> Many applications rely on operating system APIs to access DNS services. As
> native support of DNS over TLS rolls out in to operating systems it seems
> likely that some applications will wish to control the security policy that
> the operating system applies when it performs DNS resolution. For example,
> the application may wish to require that the operating system uses an
> encrypted DNS protocol.
>
>
>
> Today, most operating systems use the getaddrinfo() function described in
> RFC3493 as the basis of their API for translating DNS names to IP
> addresses, but this does not have security policy attributes.. Is anyone
> aware of any activity to enhance the RFC3493 work to add application
> control of security policy to the getaddrinfo() capabilities?
>
>
>
> Unless operating systems support secure DNS standards and expose APIs to
> allow applications to use them effectively then applications that require
> secure DNS have little choice other than to roll their own implementations.
>
>
>
>
>
> Thanks
>
>
>
> Iain
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Fwd: New Version Notification for draft-hzpa-dprive-xfr-over-tls-02.txt
On Tue, Jul 9, 2019 at 5:03 AM Sara Dickinson wrote: > All, > > An updated version of draft-hzpa-dprive-xfr-over-tls has been submitted > which contains much more detail on data flows, authentication mechanisms > and other issues than the previous version. > > Feedback and review welcomed. > > Best regards > > Sara. > > Begin forwarded message: > > *From: *internet-dra...@ietf.org > *Subject: **New Version Notification for > draft-hzpa-dprive-xfr-over-tls-02.txt* > *Date: *8 July 2019 at 18:27:36 BST > *To: *"Sara Dickinson" , "Han Zhang" < > hzh...@salesforce.com>, "Willem Toorop" , "Allison > Mankin" , "Pallavi Aras" > > > A new version of I-D, draft-hzpa-dprive-xfr-over-tls-02.txt > has been successfully submitted by Sara Dickinson and posted to the > IETF repository. > > Name: draft-hzpa-dprive-xfr-over-tls > Revision: 02 > Title: DNS Zone Transfer-over-TLS > Document date: 2019-07-08 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-hzpa-dprive-xfr-over-tls-02.txt > Status: > https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ > Htmlized: > https://tools.ietf.org/html/draft-hzpa-dprive-xfr-over-tls-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hzpa-dprive-xfr-over-tls > Diff: > https://www.ietf.org/rfcdiff?url2=draft-hzpa-dprive-xfr-over-tls-02 > > Abstract: > DNS zone transfers are transmitted in clear text, which gives > attackers the opportunity to collect the content of a zone by > eavesdropping on network connections. The DNS Transaction Signature > (TSIG) mechanism is specified to restrict direct zone transfer to > authorized clients only, but it does not add confidentiality. This > document specifies use of DNS-over-TLS to prevent zone contents > collection via passive monitoring of zone transfers. > > 4.1. AXFR Mechanism "zone is update to date" "update to" -> "up to" 4.2. "forth step" -> "fourth step" (in several places) 4.3. Data Leakage of NOTIFY and SOA Message Exchanges "This section attempts to presents a rationale" "presents" -> "present" 6.2. TLS Not sure that these are the right words. "surveillance" to me implies a passive watching. Which means: "passive surveillance" - is redundant, and "active surveillance" - is a contradiction in terms. I assume that "active" means sending packets to try to confuse the server or client, which I would call an "attack" and not "surveillance". Or am I wrong? -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt
On Mon, Mar 11, 2019 at 12:21 PM manu tman wrote: > Hi all, > > I have captured in a draft the mechanism I used during IETF 103 hackathon > and which is available aan experimental module in knot-resolver[0]. I was > taken short with time before cit-off date, but I hope this will better > explain how it works. > > Manu > > [0] > https://gitlab.labs.nic.cz/knot/knot-resolver/tree/master/modules/experimental_dot_auth > > ——— > > > > A new version of I-D, draft-bretelle-dprive-dot-spki-in-ns-name-00.txt > > has been successfully submitted by Emmanuel Bretelle and posted to the > > IETF repository. > > > > Name: draft-bretelle-dprive-dot-spki-in-ns-name > > Revision: 00 > > Title: Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name > Server name > > Document date: 2019-03-11 > > Group: Individual Submission > > Pages: 7 > > URL: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=9TmF-DXxE_0nJ6WyhRNoNSiya3N7h_pVwyRn4qIfD7U= > > Status: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=5eZd00_oyy5t1SFYXYCMfv1fSl22SudK5I3pkCozKFs= > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=ZTRurE9sjAPDCKcx8dBXgYPs0dE9LmmJ194vl04cn3Q= > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=H0At0r1sQEdFc1snO7kIVALaFf-F1zRRHGPf3aUqkk4= > > > > > > Abstract: > > This document describes a mechanism to exchange the Subject Public > > Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated > > with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding > > it as part of its name. The fingerprint can thereafter be used to > > validate the certificate received from the DoT server as well as > > being able to discover support for DoT on the server. > > 6. IANA Considerations " TODO: This document requires IANA actions (new RR type)." What new RR type is needed? Looks to me like all standard RR's. -- 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
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-padding-policy-05.txt
On Wed, Jul 18, 2018 at 8:28 AM Alexander Mayrhofer <
alex.mayrhofer.i...@gmail.com> wrote:
> Question to the broader Working Group:
>
> Shall i include the following strategy into the document at this
> stage, or should we (see "EXPERIMENTAL" document status) divert this
> into a future specification which updates or obsoletes the current
> document?
>
> I do not have an opinion on that question.
> Comments appreciated.
>
> best,
> Alex
>
> On Thu, Jun 21, 2018 at 8:57 PM, Brian Dickson
> wrote:
> > Sorry to be commenting so late in the process...
> >
> > Was the strategy of "MTU(-ish) maximum padding policy" ever suggested,
> > possibly as an alternative to Maximum Padding Policy?
> >
> > IMHO, there are signifiant benefits, even beyond privacy:
> >
> > It addresses the issues on Random that Eric R raises
> > It doesn't fragment (at least locally and/or if "Internet MTU" value(s)
> are
> > used, like 1492 or 1472 or 1452 rather than 1500 (takes into account
> > expectations on use of MPLS and/or L2 encapsulation in the middle while
> > still using "maximum-ish" padding, of fixed size per client
>
> > It largely defeats use of DNS amplification, since the query packet will
> > already be as big as the biggest response.
I thought the query and response used separate padding sizes, since queries
are typically much smaller. So an attacker could use small padding to a
server that used "maximum-ish" padding and get amplification. I don't
think we want to pad queries to more than 288?
--
Bob Harold
> Of course, it doesn't defeat
> > anonymizing attacks, it just reduces the use of authority servers for
> > strictly amplification purposes.
> >
> > Brian Dickson
> >
> > On Fri, Apr 13, 2018 at 3:47 AM 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 : Padding Policy for EDNS(0)
> >> Author : Alexander Mayrhofer
> >> Filename: draft-ietf-dprive-padding-policy-05.txt
> >> Pages : 10
> >> Date: 2018-04-13
> >>
> >> Abstract:
> >>RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
> >>the actual padding length for specific applications. This memo lists
> >>the possible options ("Padding Policies"), discusses implications of
> >>each of these options, and provides a recommended (experimental)
> >>option.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-05
> >>
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-padding-policy-05
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-padding-policy-05
> >>
> >>
> >> 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 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
Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile
On Mon, Nov 28, 2016 at 6:18 AM, Sara Dickinson <s...@sinodun.com> wrote: > > > On 18 Nov 2016, at 06:13, Shane Kerr <sh...@time-travellers.org> wrote: > > > > Warren, > > > > At 2016-11-18 13:42:08 +0900 > > Warren Kumari <war...@kumari.net> wrote: > > > >> This starts a Call for Adoption for draft-mayrhofer-dprive- > padding-profile. > >> > >> The draft is available here: > >> https://datatracker.ietf.org/doc/draft-mayrhofer-dprive- > padding-profile/ > >> > >> Please review this draft to see if you think it is suitable for > >> adoption by DPRIVE, > >> and comments to the list, clearly stating your view. > > > > I have read this draft and support its adoption by DPRIVE. > > +1 > > > > >> Please also indicate if you are willing to contribute text, review, etc. > > > > I am willing to contribute text, and review, and even etc. if necessary. > > +1 > > > > > > > > > Note there was some discussion today in the working group about the > > approach that this document takes. The concern is that this seems to be > > a survey of possible techniques. Personally I think it makes sense to > > have two documents: > > > > 1. A review of all possible approaches (the current document), and > > 2. Recommendations for implementors (based on pending research and > > analysis). > > > > If we really only want one document, then probably it should start with > > recommendations and then include the review of techniques as an > > appendix. > > I happen to favour this second approach of just one document, evolving the > structure of the draft as the recommendations become clearer. > > Sara. > I support and will review. Prefer one doc. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft
On Tue, Nov 1, 2016 at 7:09 AM, Hugo Connery <h...@env.dtu.dk> wrote:
> Hi,
>
> The document looks like a great start.
>
> You seem to be using 'strategy' (28 times) and 'profile' (8 times)
> interchangeably. You may wish to prefer one over the other, or
> clearly delineate the difference in meaning.
>
> The list of strategies looks great. Perhaps you could mention
> the "pad the message to the maximum possible message length"
> explicitly as a sub-case of "Block Length Padding".
>
> I am not recommending it, but it has the maximum "confidentiality"
> property (all EDNS messages look identical -- random noise of the same
> size). Thus, it probably deserves an explicit mention, in the same
> way that "no padding" deserves a mention as it has the minimum
> "confidentiality" property.
>
> You spell length as lenght twice in the first paragraph of section 4.5
>
> Regards, Hugo Connery
>
> On Mon, 2016-10-31 at 22:40 +0100, Alexander Mayrhofer wrote:
> > Hi,
> >
> > I've posted a first rough cut of a "Padding Profile" draft,
> > describing strategies regarding EDNS0 padding size (which we
> > specifically did *not* address in RFC 7830):
> >
> > https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00
> >
> > It's more like a "strawman proposal" rather than a polished document
> > in the current version, but i'm more than happy to talk about it in
> > Seoul if we have time. See the full I-D announcement below.
> >
> > best,
> > Alex
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title : Padding Profiles for EDNS(0)
> > Author : Alexander Mayrhofer
> > Filename: draft-mayrhofer-dprive-padding-profile-00.txt
> > Pages : 6
> > Date: 2016-10-31
> >
> > Abstract:
> >RFC 7830 specifies the EDNS0 'Padding' option, but does not
> > specify
> >the amount of padding to be used in specific applications. This
> > memo
> >lists the possible options ("Padding Profiles"), discusses the
> >implications of each of these options, and provides implementation
> >guidance.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profi
> > le/
>
>
Good start.
4.4. Random Length Padding
'Alternatively, pad a certain percentage of "remaining space"?'
-- This, like fixed length padding, is discoverable and thus of no help.
You should specifically recommend against this, in case someone else thinks
of it and does not realize the problem with it.
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
On Thu, Aug 18, 2016 at 1:14 AM, Tirumaleswar Reddy (tireddy) <
tire...@cisco.com> wrote:
> *From:* Bob Harold [mailto:rharo...@umich.edu]
> *Sent:* Wednesday, August 17, 2016 9:13 PM
> *To:* Warren Kumari <war...@kumari.net>
> *Cc:* dns-privacy@ietf.org; draft-ietf-dprive-dnsod...@ietf.org;
> dprive-cha...@tools.ietf.org
> *Subject:* Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
>
>
>
>
>
>
>
> On Tue, Aug 16, 2016 at 1:05 PM, Warren Kumari <war...@kumari.net> wrote:
>
> Dear DPRIVE WG,
>
> The authors of draft-ietf-dprive-dnsodtls have indicated that they
> believe that the document is ready, and have asked for Working Group
> Last Call.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
>
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.
>
> This WGLC ends Tue 30-Aug-2016.
>
> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> Are you personally aware of any IPR that applies to
> draft-ietf-dprive-dnsodtls? If so, has this IPR been disclosed in
> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
> for more details.)
>
> Thanks,
> Warren Kumari
>
>
>
> Looks good to me. A couple grammatical concerns:
>
>
>
> Section "3.1. Session Initiation"
>
> The last sentance might sound better by adding "therefore" in the middle:
>
>
>
> "There are
>significant security issues in mixing protected and unprotected data,
>
> therefore
>UDP connections on a port designated by a given server for DNS-over-
>DTLS are reserved purely for encrypted communications."
>
>
>
> [TR] Updated in my local copy.
>
>
>
> Section "4. Performance Considerations"
> This sentence does not read well to me:
>
> "TLS False Start] which reduces round-trips
>by allowing the TLS second flight of messages (ChangeCipherSpec) to
>also contain the (encrypted) DNS query. "
>
>
>
> [TR] How about the following line ?
>
> TLS False Start [I-D.ietf-tls-falsestart] can reduce the round-trips in
> certain situations.
>
[BH] That would work.. I was think just change "which reduces" to "can
reduce":
"TLS False Start] can reduce round-trips
by allowing the TLS second flight of messages (ChangeCipherSpec) to
also contain the (encrypted) DNS query. "
>
>
> -Tiru
>
>
>
> --
>
> Bob Harold
>
>
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
On Tue, Aug 16, 2016 at 1:05 PM, Warren Kumari <war...@kumari.net> wrote:
> Dear DPRIVE WG,
>
> The authors of draft-ietf-dprive-dnsodtls have indicated that they
> believe that the document is ready, and have asked for Working Group
> Last Call.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
>
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.
>
> This WGLC ends Tue 30-Aug-2016.
>
> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> Are you personally aware of any IPR that applies to
> draft-ietf-dprive-dnsodtls? If so, has this IPR been disclosed in
> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
> for more details.)
>
> Thanks,
> Warren Kumari
> <https://www.ietf.org/mailman/listinfo/dns-privacy>
Looks good to me. A couple grammatical concerns:
Section "3.1. Session Initiation"
The last sentance might sound better by adding "therefore" in the middle:
"There are
significant security issues in mixing protected and unprotected data,
therefore
UDP connections on a port designated by a given server for DNS-over-
DTLS are reserved purely for encrypted communications."
Section "4. Performance Considerations"
This sentence does not read well to me:
"TLS False Start [I-D.ietf-tls-falsestart] which reduces round-trips
by allowing the TLS second flight of messages (ChangeCipherSpec) to
also contain the (encrypted) DNS query. "
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)
On Mon, Nov 16, 2015 at 10:31 AM, Watson Ladd <watsonbl...@gmail.com> wrote: > On Mon, Nov 16, 2015 at 10:28 AM, Olafur Gudmundsson <o...@ogud.com> > wrote: > > > >> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <g...@araneus.fi> > wrote: > >> > >> Shane Kerr wrote: > >>> Andreas Gustafsson <g...@araneus.fi> wrote: > >>>> > >>>> I'm also wondering if there might be scenarios where the messages are > >>>> compressed before encryption. If that is the case, padding with zeros > >>>> is of limited value because they will mostly compress away, and the > >>>> ability to send data of similar compressibility to actual payload > >>>> data, or data of unpredictable compressibility, would be useful. > >>> > >>> It's an interesting idea, but I think I'd like to see some solid > >>> research on this. We understand how to add 0 bytes; I don't personally > >>> understand the implications of generating "similarly compressible" data > >>> to prevent attackers from doing traffic analysis. > >>> > >>> My own feeling is that we should proceed with 0-padding, and perhaps > >>> consider alternate schemes later if there is good guidance in the area > >>> of non-empty padding. > >> > >> We can certainly proceed with *sending* 0-padding. All I'm asking is > >> for receivers not to reject messages with nonzero padding, so that if > >> alternate schemes are introduced in future senders, they can > >> interoperate with existing receivers. > > > > +1 All resolvers should ignore the contents padding > > > >> > >>> Surely academics have looked at this! Do you have pointers to some > >>> papers covering this approach? > >> > >> I'm afraid not. > > > > Shane, > > > > There is lots of work in this area, but it is trivial to reason about > the issue from DNS perspective > > Goal: hide how long the query name is, to defeat traffic analysis. > > > > Padding of the same value in each byte can be compressed to almost > nothing ==> same as having no padding, ==> failed to meet goal. > > TLS by default in many cases, compresses before transmission, ==> DNS > padding option must defeat compression > > This is a problem that is easily fixed: turn off compression. TLS 1.3 > is eliminating compression for similar reasons. > > > > > I think the WG should consider if the current text of saying use 0x00 is > not good enough, > > there are 3 options, use: > > - 0x00 > > - cheap randomness > > - real randomness source > > > > I think the middle one is good enough, a simple seeded hash function > i.e. HMAC is sufficient or /dev/urandom > > > > Olafur > > The reason they wanted 0-padding, and to be verified by the receiver is to prevent that data from being used as a hidden communication channel by viruses. Changing that to random, or not checked, is therefore a problem. But then it is compressible, which is a different issue. I don't see an easy solution. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-am-dprive-eval-02
On Mon, Nov 2, 2015 at 4:29 AM, Tim WIcinski <tjw.i...@gmail.com> wrote: > > (no hats) > > With this new version, I think the document is useful and provides a solid > discussion of how to quantify privacy mechanisms for a DNS implementer who > is not a security subject matter expert. > > tim > On 11/2/15 6:22 PM, Andrew Sullivan wrote: > >> Despite my comments against the hum at the mic, I have read this >> document and think it should certainly be adopted. I just don't want >> Yet Another Meaningless Commitment. (If you looked before and can't >> fact it again, give it a try. It's much improved.) >> >> A >> >> > This looks useful. I have a few concerns. https://tools.ietf.org/html/draft-am-dprive-eval-02 pg 3, section 2 "reasability" -> "readability" Also, these sentences seem redundant: "The verbatim source of most of those definitions is from [RFC6973], which are included as an aid in reasability." and "For the terms from [RFC6973], we include their definitions rather than simply referencing them as an aid to readability." pg 5, sec 2.4, end of first paragraph: "In this section, we outline such definitions we further notes on their indications." That sentence seems incomplete around the word "we". Perhaps "we" -> "with". pg 12, sec 6, last paragraph, "Composed (Multiple) Mechanisms": "than either of the two along." -> than either of the two alone." pg 14, sec 7.2 says: "the probability that one query is comes from a given individual is (1/10 = 0.1). The probability that two queries are issued by the same initiator is 0.1^2 = 0.01, which represents the linkability probability. The unlinkability probability is given as 1-0.01 = 0.99." Does "same initiator" mean "a given individual"? Or just "second packet is from same initiator as the first packet" I think we should distinguish between linking to an initiator and linking between packets:: -- The probability that two queries are issued by "a given individual" is 0.1^2 = 0.01 -- The probability that two queries are issued by the same initiator, meaning the second packet is from the same initiator as the first, is 0.1. pg 17, sec 7.4 I am not familiar with the details of IPSEC, but from the text it appears to hide the port number. But does it hide the destination IP? If not, and if most DNS resolvers have a separate IP from other services, then "undetectability" is very low, since any communication with the IP of the DNS resolver is most likely a DNS query. (For purposes of the illustration, perhaps you should clearly state the you are assuming a resolver on a shared IP that does much more than just DNS resolution.) -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
On Thu, Oct 22, 2015 at 2:05 PM, Wessels, Duane <dwess...@verisign.com> wrote: > > > On Oct 22, 2015, at 6:59 PM, Bob Harold <rharo...@umich.edu> wrote: > > > > The URL is not working for me, and I cannot find a working URL. Is it > just me? > > > Try this: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/ > > Thanks Tim and Duane, looks good to me. -- 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-start-tls-for-dns-00.txt
One minor concern: Page 8, section 4, point 4 Use of a local DNS forwarder allows a single active DNS-over-TLS connection allows a single active TCP connection for DNS per client computer. -- That sentence does not read correctly to me. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Privacy for engineers
Good reading, but I cannot agree with the definition of PII is clear cut. Rather *any* information pertaining to an identifiable individual is extremely vague. And when they want us to try to 'secure' information that is already 'public', we have to scratch our heads and wonder. But at least he admits that there are tradeoffs. The law (or a typical organization's policy) does not seem to understand that. Disclaimer: definitely not speaking for my employer. -- Bob Harold On Mon, Oct 27, 2014 at 3:46 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Good reading about the blind spots of engineers about privacy: http://lockstep.com.au/blog/2014/08/28/engineers-and-privacy ___ 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
