Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

On Tue, Mar 28, 2023 at 09:29:46PM +0900, Ralf Weber wrote a message of 30 lines which said: > As I don’t think probing for secure transport is a good idea and > hope that we will come up with better solutions that follows the DNS > delegation model. You mean the parent announcing the zone

[dns-privacy] IETF 116 hackathon on ADoT unilateral probing

[Already sent on the list but, apparently, some people missed it and asked for it to be in its own thread.] Following the work done at the DNS table, during the hackathon: * PowerDNS Recursor implements unilateral probing (but not *this* unilateral probing, it differs from the draft, see the

Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

On Mon, Mar 27, 2023 at 11:03:17AM +, Paul Hoffman wrote a message of 8 lines which said: > Thanks for the implementation work at the Hackathon, and thanks to > Libor and Florian for the comments. Given that we are in WG Last > Call, we (the co-authors) will deal with them in the coming >

Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

On Mon, Mar 20, 2023 at 10:35:07AM +0100, Joey Salazar wrote a message of 115 lines which said: > On this note, we the authors want to invite folks to participate in > this week's Hackathon: I'll be there on Sunday and Benno and Yorgos > from NLnet Labs will be there since Saturday working on

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 02:32:46PM +0100, Jim Reid wrote a message of 13 lines which said: > > RFC 7626 (the threat model and problem analysis that some people > > claim is missing) is clear (section 2.5.2 for instance). > > RFC7626 is 6 years old. RFC 793 is 39 years old. Let's drop TCP

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 10:12:52PM +, Andrew Campling wrote a message of 30 lines which said: > My apologies if the stance of TLD operators is well known to most in > this group, I don't think so, this they are a very diverse group, working under very different conditions. > do

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 11:43:57PM +0200, Bill Woodcock wrote a message of 74 lines which said: > This isn’t a place for pointless thrashing around as a byproduct of > someone’s unrelated agenda. Which was, I think, the point of the > statement. But I wonder again who this "someone" is? I

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 02:12:03PM +0100, Jim Reid wrote a message of 15 lines which said: > But the WG doesn’t seem to want to consider that. But what DPRIVE could do here? RFC 8806 is published. Besides sending its successor on the standards track, what do you suggest the group to do?

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 03:15:14PM +0200, Vladimír Čunát wrote a message of 11 lines which said: > So far I haven't noticed anyone pushing for encryption to the root. Indeed. And this is why the root server operators statement is surprising. It looks like a reply to some pressure to encrypt,

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 01:00:43PM +, Hollenbeck, Scott wrote a message of 38 lines which said: > [SAH] Why assume that encryption is required to provide confidentiality? We never assumed that. RFC 7626 (the threat model and problem analysis that some people claim is missing) is clear

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Wed, Mar 31, 2021 at 10:44:08AM +0200, Vladimír Čunát wrote a message of 12 lines which said: > it's not so difficult to completely avoid querying root servers, > through one of the "local root" approaches. RFC 8806 does not seem mentioned in the statement. Does anyone know why?

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Tue, Mar 30, 2021 at 05:53:59PM -0700, Erik Kline wrote a message of 111 lines which said: > I think, "IN NS com." doesn't reveal much information. But perhaps > "IN NS sensitive-tld." could have privacy implications for some > folks? ir? cu? gay? Also, while com/NS will be in the

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Tue, Mar 30, 2021 at 05:19:29PM -0700, Rob Sayre wrote a message of 69 lines which said: > The DNSSEC stuff stood out to me. Why is that even seen as something that > would help? Because one of the ways to improve privacy at the root is local synthesis of answers by the resolver,

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

On Tue, Mar 30, 2021 at 05:00:29PM -0700, Rob Sayre wrote a message of 56 lines which said: > Why can't "The Root Server Operators" run QUIC etc as well as their > existing UDP methods? Just a note that DNS-over-QUIC is far from standard currently.

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

On Mon, Nov 02, 2020 at 02:54:13PM -0800, internet-dra...@ietf.org wrote a message of 43 lines which said: > Title : DNS Privacy Requirements for Exchanges between > Recursive Resolvers and Authoritative Servers > Authors : Jason Livingood >

Re: [dns-privacy] Requirements for authoritative server preferences

On Wed, Nov 04, 2020 at 02:15:03AM +, Paul Hoffman wrote a message of 114 lines which said: > In addition this SHALL include whether a secure transport protocol > MUST always be used (non-downgradable) or whether a secure > transport protocol MAY be used on an

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

On Mon, Nov 02, 2020 at 02:54:13PM -0800, internet-dra...@ietf.org wrote a message of 43 lines which said: > Title : DNS Privacy Requirements for Exchanges between > Recursive Resolvers and Authoritative Servers > Authors : Jason Livingood >

Re: [dns-privacy] Fw: New Version Notification for draft-yan-dprive-local-service-indication-02.txt

On Mon, Jul 13, 2020 at 10:17:57AM +0800, Z.W. Yan wrote a message of 120 lines which said: > The motivation of this draft is to actively indicate the privacy > protection capability of the recursive server. The approach in draft-ietf-dnsop-resolver-information seems better since: * it is

Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-13.txt

On Fri, Jul 10, 2020 at 09:41:07AM +0100, Sara Dickinson wrote a message of 61 lines which said: > This version should address the final comments from the IESG review. Some very small editorial details: Abstract "to assist writers of a Recursive operator Privacy statement" Capital S, for

Re: [dns-privacy] Datatracker State Update Notice:

On Mon, May 11, 2020 at 12:35:11PM -0700, Christian Huitema wrote a message of 294 lines which said: > The paragraph in section 5.1 seems to imply that embedding a > recursive resolver in the end point or close to reduces the privacy > attack surface: Note that it was already in RFC 7626

Re: [dns-privacy] Datatracker State Update Notice:

On Tue, May 12, 2020 at 02:14:43PM +0200, Vittorio Bertola wrote a message of 144 lines which said: > Every time the authors put the effort to rewrite it once again > according to the comment, and every time a new comment comes in > saying that this is not enough. I admire their patience.

Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-09.txt

On Mon, May 04, 2020 at 01:06:10PM -0400, Bob Harold wrote a message of 156 lines which said: > 7.1.2. Trust Model Bootstrapping > > The whole first paragraph is difficult to parse - it does not seem like > complete sentences. Do we talk about the same draft? There is no "7.1.2. Trust

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-00.txt

On Sun, Dec 15, 2019 at 07:33:04AM -0800, internet-dra...@ietf.org wrote a message of 35 lines which said: > Title : DNS Privacy Requirements for Exchanges between > Recursive Resolvers and Authoritative Servers > Authors : Jason Livingood >

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

On Thu, Jan 09, 2020 at 10:29:29AM -0800, Eric Rescorla wrote a message of 181 lines which said: > > It means a standards compliant DoT implementation will have no > > client identifiers, a standards compliant DoH implementation is > > free to (and likely) to include them. > > > > [Citation

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

On Wed, Jan 01, 2020 at 10:45:58PM -0800, S Moonesamy wrote a message of 63 lines which said: > There are currently four (IETF) working groups focused on DNS with three of > them having privacy as part of their charter. doh, dnssd and dprive (plus dnsop)? > Section 1 of the draft has a

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Tue, Jan 07, 2020 at 02:47:02PM -0800, Eric Rescorla wrote a message of 310 lines which said: > Yeah, my point is that I don't agree with this. Right now there is a > lot of ISP centralization and the move of some of that traffic to > public resolvers potentially decreases centralization

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Tue, Jan 07, 2020 at 06:37:38PM +, Sara Dickinson wrote a message of 278 lines which said: > There is currently no standardized discovery mechanism for DoH and > Strict DoT servers so applications that might want to dynamically > discover such encrypted services are not able to. At the

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Tue, Jan 07, 2020 at 06:39:18PM +, Sara Dickinson wrote a message of 194 lines which said: > > on the basis that it assumes that these optimizations are deployed > > without regard to privacy. May be just an informative reference to RFC 7231, specially section 9.7, would please

[dns-privacy] DNS stamps

Could be useful specially for secure and public resolvers, may be worth of some IETF work? https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On Wed, Nov 27, 2019 at 10:04:57AM +, Neil Cook wrote a message of 45 lines which said: > I don’t see why they’re broken by design; You explained it well: > they add no security properties > on top of the (insecure) DHCP mechanism used to contact the resolver > in the first place And

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On Wed, Nov 27, 2019 at 09:07:15AM +, Konda, Tirumaleswar Reddy wrote a message of 72 lines which said: > > *All* "automatic discovery of the DoH resolver" schemes are broken > > by design and I really wonder why people keep suggesting them. > > Not all discovery mechanisms have security

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On Tue, Nov 26, 2019 at 09:51:14AM -0800, Brian Dickson wrote a message of 98 lines which said: > However, if the only place the client is able to establish an > encrypted path to is a forwarder, this leave open the possibility > that the forwarder->(forwarder->[...])->resolver might involve

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On Tue, Nov 26, 2019 at 12:35:13PM -0500, Phillip Hallam-Baker wrote a message of 166 lines which said: > 2) Admin/User Configured DNS > The client obtains the information to connect to a resolver through an > Administrator or User configuration action. This may be inserting an IP >

Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

On Wed, Nov 06, 2019 at 01:16:29PM +, Sara Dickinson wrote a message of 241 lines which said: > The current usage is the result of a discussion on the very first > version of the draft (draft-dickinson-dprive-bcp-op-00, June 2018) > and since then (limited) usage of RFC2119 language has

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

On Mon, Nov 04, 2019 at 08:20:05AM -0800, Tommy Pauly wrote a message of 45 lines which said: > However, there are a couple reasons we're interested in having DoH > servers directly support receiving Oblivious queries: Ok, but these reasons should be put in the draft (may be in an appendix),

Re: [dns-privacy] ADoT signalling

On Sun, Nov 03, 2019 at 05:33:34PM -0500, John Levine wrote a message of 14 lines which said: > I thought it might be useful to make a list of possible ways to signal > that a server offers ADoT: I would like also a discussion on whether signaling is 1) good 2) necessary. Even if you get a

Re: [dns-privacy] ADoT signalling

On Sun, Nov 03, 2019 at 05:33:34PM -0500, John Levine wrote a message of 14 lines which said: > I thought it might be useful to make a list of possible ways to signal > that a server offers ADoT: > > https://datatracker.ietf.org/doc/draft-levine-dprive-signal/ > > I'm sure there are others,

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

On Fri, Nov 01, 2019 at 03:40:51PM -0700, Tommy Pauly wrote a message of 393 lines which said: > We've posted new versions of our drafts on discovering designated DoH > servers, and Oblivious DoH: If you want to separate the knowledge of the source IP address and the knowledge of the QNAME,

Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

On Thu, Oct 31, 2019 at 11:24:45AM -0400, Tim Wicinski wrote a message of 113 lines which said: > This starts a Second Working Group Last Call for draft-ietf-dprive-bcp-op Background: I run a small (very small) public DoH and DoT resolver, and it has a DROP (a policy). If you want to read

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

On Tue, Mar 12, 2019 at 04:55:11PM +0100, Neil Cook wrote a message of 22 lines which said: > Actually many enterprises (particularly banks etc.) do not allow DNS > resolution directly from employee endpoints. They block UDP/53, which is not the same thing. Malware or non-cooperating

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

On Sun, Mar 10, 2019 at 11:17:43PM -0700, Paul Vixie wrote a message of 36 lines which said: > > You claim the right to impose your rules, because it is "your network". > > Yet you have to define ownership. > my network, my rules. your provider's network, their rules. I clearly disagree. If

Re: [dns-privacy] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

On Mon, Mar 11, 2019 at 09:59:11AM +0530, nalini elkins wrote a message of 231 lines which said: > Companies also (validly, in my opinion) wish to know if their > employees are going to fantasyfootballgame.com while they are > supposedly doing work and of course, other sites which people

Re: [dns-privacy] New: draft-bertola-bcp-doh-clients

On Sun, Mar 10, 2019 at 10:24:56PM -0700, Paul Vixie wrote a message of 82 lines which said: > set up a war between end users and network operators, Well, the tussle already exists. It does not depend on whether you like it or not, on whether the IETF approves it or not. When people have

Re: [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients

On Mon, Mar 11, 2019 at 08:55:18AM +0530, nalini elkins wrote a message of 202 lines which said: > The questions that the Fortune 50 company architect asked were something > like this: > > 1. You mean that DNS could be resolved outside my enterprise? I suggest to explain to this person that

Re: [dns-privacy] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Tue, Mar 12, 2019 at 08:14:49PM +1100, Mark Nottingham wrote a message of 32 lines which said: > I'm also very conscious that we had a side meeting about similar > issues in Singapore (IIRC), and didn't make much progress at all in > that time. This time, we have drafts (poor ones, IMHO,

Re: [dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 06:57:03PM +0100, Vittorio Bertola wrote a message of 18 lines which said: > Moreover, centralization is not the only Do*-related problem > category that has been raised (my draft alone lists eight others). IMHO, this is precisely the biggest problem with these three

Re: [dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 01:59:25PM -0400, Allison Mankin wrote a message of 94 lines which said: > Perfect idea, very good use of the Wednesday slot. New date and place registered at , wednesday, Karlin 1/2, 1500 to 1700. (Note

Re: [dns-privacy] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 10:06:21AM -0700, Ted Hardie wrote a message of 76 lines which said: > This conflicts with SECDISPATCH, which will have a pretty serious impact on > who might attend. Scheduling these things is very hard, obviously. Given > this topic, you may have to move outside the

[dns-privacy] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Resent with the correct list of working groups.] [Sorry for the long list of working groups but the discussion already started in different places.] There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484) deployment and the risk of centralization of Internet services. (See for

Re: [dns-privacy] DoT between recursive and authoritative pilot

On Fri, Dec 21, 2018 at 06:59:43PM -0800, manu tman wrote a message of 43 lines which said: > As some you already know, Cloudflare and Facebook have been running a pilot > on using DoT between Cloudflare DNS and Facebook authoritative name servers. > You can read more about it at >

[dns-privacy] Is there a draft for Knot "Experimental DNS-over-TLS Auto-discovery"

was already mentioned in the discussion about encoding keys in names. But is there a draft for this trick? I cannot find one. ___ dns-privacy mailing

Re: [dns-privacy] Fwd: New Version Notification for draft-annee-dprive-oblivious-dns-00.txt

On Sat, Jul 14, 2018 at 09:13:56PM -0400, Nick Feamster wrote a message of 40 lines which said: > 1. Tor is vulnerable to DNS fingerprinting, particularly at the > recursive resolver. Many Tor exits use Google public DNS (~40%, by > exit throughput), I know this research but I don't see the

Re: [dns-privacy] Fwd: New Version Notification for draft-annee-dprive-oblivious-dns-00.txt

On Tue, Jul 03, 2018 at 06:18:51PM -0400, Ben Schwartz wrote a message of 293 lines which said: > My main question for the authors is: how does this compare to > routing a DNS-over-TLS socket through a TCP forwarder? Isn't it what Tor is doing? Reasons to use Tor: * well known and studied,

[dns-privacy] RIPE Atlas probes can now test DNS-over-TLS

The RIPE Atlas probes, really useful for testing Internet servers from several vantage points, can now do DNS-over-TLS. Starting with version 1.1.4, the blaeu program (article in , source code

Re: [dns-privacy] dprive - Requested session has been scheduled for IETF 101

On Tue, Feb 27, 2018 at 03:11:25PM -0800, "IETF Secretariat" wrote a message of 45 lines which said: > dprive Session 1 (1:30:00) > Wednesday, Afternoon Session I 1330-1500 > Room Name: Balmoral size: 250 Now, we just need an agenda.

Re: [dns-privacy] representation of DNS transport in use?

On Sat, Mar 10, 2018 at 08:20:27PM +0900, Erik Kline wrote a message of 165 lines which said: > TL;DR: Should we have some kind of URI schemes for encrypted DNS > protocols (i.e. identifying the transport)? dns+tls: ? (To follow the COAP example of RFC 8323, section 8.) May

Re: [dns-privacy] Fwd: New Version Notification for draft-dickinson-bcp-op-00.txt

On Tue, Mar 06, 2018 at 10:42:10AM +, Sara Dickinson wrote a message of 198 lines which said: > There is a new draft (very much a placeholder at the moment) that > attempts to start the discussion around Best Practices for Operators > of DNS Privacy Services. It is

Re: [dns-privacy] IETF101 Call for Agenda Requests

On Mon, Feb 19, 2018 at 05:41:33PM -0500, Tim Wicinski wrote a message of 14 lines which said: > DPRIVE is slated for Wednesday 21 March, 2018  in the first afternoon slot > (13:30-15:00) > > This is a call for requests for agenda topics.

[dns-privacy] New dnscrypt Web site

https://dnscrypt.info You'll note that the FAQ includes a comparison with IETF solutions. Some remarks: 1) dnscrypt "Cannot be MITM’d by standard tools" vs. DNS-over-TLS "Readily compatible with industry-standard TLS interception/monitoring devices" This seems a

Re: [dns-privacy] WG Last Call: draft-ietf-dprive-padding-policy-03.txt

On Mon, Jan 22, 2018 at 02:00:16PM +, Stephen Farrell wrote a message of 241 lines which said: > - Is there any (good) literature on related mechanisms that one > might use to further increase the difficulties of traffic analysis > based on DNS traffic? I'm

[dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-resolver-to-auth-00.txt]

and criticisms welcome. --- Begin Message --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Encryption and authentication of the DNS resolver-to-authoritative communication Author : Stephane Bortzmeyer Filename

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Fri, Oct 27, 2017 at 11:40:15PM -0400, Daniel Kahn Gillmor wrote a message of 219 lines which said: > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic > metaquery, I see the point

[dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked?

The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles has a DISCUSS "This needs to be updated to indicate that the client MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise you're going to have interop problems." The DISCUSS was against -09, the current version is

[dns-privacy] Android getting “DNS over TLS” support to stop ISPs from knowing what websites you visit

[There was a demo at the Bits-n-Bites in the last meeting, Prague.] https://www.xda-developers.com/android-dns-over-tls-website-privacy/amp/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Usage on DNS-over-TLS on IETF Network

On Tue, Jul 18, 2017 at 01:29:27PM +0200, tjw ietf wrote a message of 5937 lines which said: > Our former co-chair Warren sent us these slides on DNS usage on the > IETF network and also DPRIVE usage. It's a small number (but not > zero!) It also would be interesting to

[dns-privacy] Padding policies draft

draft-ietf-dprive-padding-policy is now expired. Anyone knows what happens? I think that the results presented by Daniel Kahn Gillmor at NDSS were very promising (allowing to base policies on facts). ___ dns-privacy mailing list dns-privacy@ietf.org

Re: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS)

On Wed, Jun 07, 2017 at 12:25:25AM +0530, Suresh Krishnan wrote a message of 42 lines which said: > > If so, let me give my opinion: I disagree with the DISCUSS. > > Not sure what you are disagreeing with. Are you saying this text is > clear about what is needed

Re: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS)

On Tue, May 09, 2017 at 08:43:15PM -0700, Suresh Krishnan wrote a message of 37 lines which said: > I do have a concern regarding section 7.3 as it is not clear what > really is being requested on the DHCP front here. While using an IP > address or an FQDN are

[dns-privacy] Nagios/monitoring plugin for a DNS-over-TLS server?

Not yet an official plugin for monitoring my DNS-over-TLS server (nothing in ). Should I develop one at the next hackathon in Chicago? :-) I assume it is possible/easy with C/getdns

[dns-privacy] "SFMap: Inferring Services over Encrypted Web Flows Using Dynamical Domain Name Graphs"

This research (still under embargo) seems relevant to this working group: Most modern Internet services are carried over the web. A significant amount of web transactions is now encrypted and the transition to encryption has made it difficult for network operators to understand traffic mix.

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, Dec 14, 2016 at 12:18:17PM +0100, Shane Kerr wrote a message of 87 lines which said: > So basically you are advocating a model where meta-data > (specifically lookups of NS records and their associated A/ > records) is public and other data is private?

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, Dec 14, 2016 at 12:37:39PM +0100, Shane Kerr wrote a message of 65 lines which said: > If only there was a way to publish information about a server's > preferences There is one: DANE (at least to express that you support - or not - TLS and DTLS). For

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

On Wed, Dec 14, 2016 at 07:43:28AM +, Stephen Farrell wrote a message of 317 lines which said: > > Yes, will add the above text to a new Section (named "Document > > Status") > > Great. I think it is not really necessary, the status Experimental of

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Tue, Dec 13, 2016 at 11:16:08AM -0800, Paul Hoffman wrote a message of 60 lines which said: > If what we invent has better characteristics than DTLS or TLS, that > means that the TLS WG failed to find something that we could. That > seems *incredibly* unlikely, given

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, Dec 14, 2016 at 10:21:13AM +0100, Shane Kerr wrote a message of 90 lines which said: > > Given that a fallback to TCP/TLS is likely needed even if the > > right answer is QUIC, and given that however the WG decide to > > address server authentication and

Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

On Tue, Dec 13, 2016 at 03:22:50PM +, Sara Dickinson wrote a message of 51 lines which said: > > I'm still a bit concerned about the issue of detection (that there > > is an attack). Detection for passive attacks is only possible if > > there is a prior history, unlike

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Tue, Dec 13, 2016 at 03:46:25PM +0100, Shane Kerr wrote a message of 120 lines which said: > I think that TLS may be more painful in the resolver-to-auth case, > as TCP Fast Open will be generally less useful, right? Same thing (even worse) for persistent TCP

Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

On Thu, Dec 08, 2016 at 09:51:51AM +, Sara Dickinson wrote a message of 138 lines which said: > Just to follow up on Tim’s mail. Any reviews of > https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ >

[dns-privacy] New version of draft-bortzmeyer-dprive-step-2

T., Wing, D., and P. Patil, "Specification for DNS over Datagram Transport Layer Security (DTLS)", draft- ietf-dprive-dnsodtls-12 (work in progress), September 2016. [dnscurve] Bernstein, D., "DNSCurve: Usable security for DNS&qu

Re: [dns-privacy] DPRIVE meeting in Seoul - Friday, Afternoon Session I 1150-1320

On Mon, Oct 24, 2016 at 10:22:07AM +0200, Warren Kumari wrote a message of 20 lines which said: > Just wanted to let y'all know that we drew the short stick, and have > been scheduled for Friday afternoon. But no agenda published yet?

Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile

On Thu, Oct 06, 2016 at 02:58:09AM -0400, Tim Wicinski wrote a message of 28 lines which said: > This starts a Working Group Last Call for: >draft-ietf-dprive-dtls-and-tls-profile Executive summary: OK for me, draft-ietf-dprive-dtls-and-tls-profiles-03 can (and

[dns-privacy] "A Study of Privacy and Anonymity in the DNS"

At the next OARC workshop: https://indico.dns-oarc.net/event/25/session/5/contribution/26 A Study of Privacy and Anonymity in the DNS Speakers Christopher WOOD Primary authors Christopher WOOD (UCI) Co-authors Prof. Gene TSUDIK (UCI) Cesar GHALI (Google) Content The need

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

On Wed, Aug 03, 2016 at 03:26:08PM +0200, Shane Kerr wrote a message of 116 lines which said: > While the draft mentions that resolvers are configured by IP address > and authoritative servers by name, actually when a resolver is talking > to an authoritative server

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

On Tue, Aug 16, 2016 at 01:05:40PM -0400, Warren Kumari wrote a message of 38 lines which said: > https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/ I've read it (the last version, -10) and, for me, it is OK, and ready to be sent to the next step. I would like

Re: [dns-privacy] After the DNS-over-DTLS WGLC...

On Fri, Aug 19, 2016 at 04:26:17PM +0100, Sara Dickinson wrote a message of 16 lines which said: > I couldn’t find a date anywhere - when does the WGLC for > draft-ietf-dprive-dnsodtls end? >From the original message by Warren: This WGLC ends Tue 30-Aug-2016.

[dns-privacy] Dowse: "the privacy hub"

For your information. This project is about a future home router which, by default, tries hard to preserve privacy. One of the interesting thing for us is that DNS requests are transparently intercepted by the router, encrypted (with DNScrypt) and sent to a public resolver.

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

On Wed, Jul 06, 2016 at 01:54:12PM +, Prashanth Patil (praspati) wrote a message of 61 lines which said: > The new revision addresses comments received on the list and @IETF-95. My review of -07 : I see no reason not to move it to WG last call. Technical : > DNS

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

On Tue, Jul 19, 2016 at 12:07:29PM -0400, Robert Edmonds wrote a message of 18 lines which said: > Why port 953? I thought the registration for the “domain-s” port was > 853? It was a bug. It is fixed in the Github repository and the fix will be published in -01.

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

On Tue, Jul 19, 2016 at 11:28:12AM -0400, Bob Harold wrote a message of 63 lines which said: > why talk to port 953 That was a typo, it will be fixed in -01 > I was assuming normal unencrypted DNSSEC to get the key, For privacy, encrypted-but-unauthenticated is

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

On Tue, Jul 19, 2016 at 11:11:18AM -0400, Bob Harold wrote a message of 130 lines which said: > I would think that "Key in DNS, authenticated by DNSSEC" would be > the obvious choice. It is mentioned, section 2.2. For the -00 version, I did not try to order ("obvious" or

[dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

Internet-Drafts directories. Title : Next step for DPRIVE: resolver-to-auth link Author : Stephane Bortzmeyer Filename: draft-bortzmeyer-dprive-step-2-00.txt Pages : 6 Date: 2016-07-18 Abstract

Re: [dns-privacy] Deployment issues

On Mon, Jun 06, 2016 at 09:35:42AM -0700, John Heidemann wrote a message of 53 lines which said: > Other well approaches are striping queries across multiple servers, > and adding "chaff" queries. (I'm not sure that those approaches > require standardization---they could be

Re: [dns-privacy] Deployment issues

On Fri, Jun 03, 2016 at 01:33:32PM -0400, Paul Wouters wrote a message of 40 lines which said: > You would chain various DNS caches together, so a query to one > populates them all. Cool idea. We could take inspiration from RFC 2186/2187.

Re: [dns-privacy] Recharter discussion? (was DPRIVe Agenda requests for Berlin)

On Mon, Jun 06, 2016 at 07:19:31AM -0400, Tim Wicinski wrote a message of 79 lines which said: > We started the discussion a few meetings back that we are planning > on recharting to address the resolver-to-authority session. We > (warren and myself) wanted to wait until

Re: [dns-privacy] Stephen Farrell's Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

On Tue, Mar 01, 2016 at 02:07:05AM -0800, Stephen Farrell wrote a message of 43 lines which said: >[1] http://kpdyer.com/publications/oakland2012-peekaboo.pdf >[2] http://arxiv.org/pdf/1410.2087v2.pdf And besides these two papers (I liked the first one, I

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-05.txt

On Wed, Mar 16, 2016 at 04:54:33AM +, Tirumaleswar Reddy (tireddy) wrote a message of 64 lines which said: > This revision addresses comments from Stephane. Yes, I like the new text in the Security Considerations. But I'm not completely happy with the changes. 1)

Re: [dns-privacy] Call for agenda for DPRIVE at IETF95 (BA).

On Tue, Mar 15, 2016 at 12:52:00AM +, Warren Kumari wrote a message of 57 lines which said: > We have some agenda time for DPRIVE in Buenos Aires, please let us > know is you need some agenda time to present. I cannot speak for the authors of these drafts but I think

[dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt

On Fri, Jan 22, 2016 at 05:51:22AM +, Tirumaleswar Reddy (tireddy) wrote a message of 62 lines which said: > This revision addresses comments from Christian and refers to > draft-dgr-dprive-dtls-and-tls-profiles. > Title : DNS over DTLS (DNSoD) >

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-03.txt

On Mon, Jan 04, 2016 at 04:11:18PM -0800, internet-dra...@ietf.org wrote a message of 53 lines which said: > Filename: draft-ietf-dprive-dns-over-tls-03.txt A few remarks, nothing to endanger the WG consensus :-) The draft mentions DNScurve, a

Re: [dns-privacy] DNS PRIVate Exchange

On Fri, Jan 15, 2016 at 11:31:09AM +0500, Tariq Saraj wrote a message of 80 lines which said: > Unfortunately plaintext is known, As I said, it is not. You can sometimes *guess* some of the questions and answers (it is safe to assume that the user's machine will query

  1   2   >