Re: [dns-privacy] [Ext] Intended Status for draft-ietf-dprive-unilateral-probing

On Mar 6, 2023, at 08:53, Hollenbeck, Scott wrote: > > The intended status is a > factor in the development of those license terms. I find it more the other way around. Those lPR claims can be a factor in whether to make the intended status standard or experimental, or even whether to aban

[dns-privacy] Fwd: Next steps : draft-ietf-dprive-unilateral-probing

I think this message bounced back to me. Resending. Begin forwarded message: > From: Paul Wouters > Date: June 27, 2023 at 21:15:43 EDT > To: Brian Haberman > Cc: "dns-privacy@ietf.org" > Subject: Re: [dns-privacy] Next steps : draft-ietf-dprive-unilateral-probing

Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09

On Aug 1, 2023, at 16:37, Brian Haberman wrote: > >  > As document shepherd... > >> Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in >> the format from RFC 7942, and is not at all definitive, and thus can be >> removed. > >

Re: [dns-privacy] Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with DISCUSS and COMMENT)

On Sep 19, 2023, at 09:01, Rob Wilton (rwilton) wrote: > > Hi Paul, > > One question/comment on one of your discuss comments inline > [Rob Wilton (rwilton)] > > This makes sense, but do we know what proportion of authoritative servers > will have DoT/DoQ enabled? E.g., is this something

Re: [dns-privacy] [Ext] Roman Danyliw's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

On Tue, 19 Sep 2023, Paul Hoffman wrote: We don't know. It was pointed out in the WG discussion that some PKIX libraries do different types of verification regardless of what you want them to do. Yes, exactly. Even if you can't stop your library from verifying, you must be able to ignore th

Re: [dns-privacy] [Ext] Roman Danyliw's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

On Wed, 20 Sep 2023, Paul Hoffman wrote: That might not be the case. As with "null encryption", these modes are more and more being removed from code bases to avoid exploits. At that point, you couldn't use the library any more, correct? At that point, you would not have a library anymore th

Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)

On Wed, 23 Apr 2014, Nicholas Weaver wrote: b: DO NOT USE PORT 53 for this: There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS over DNS. Yes, I fully agree with this. It was a ma

Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)

On Wed, 23 Apr 2014, Nicholas Weaver wrote: On Apr 23, 2014, at 1:00 PM, Paul Wouters wrote: No, I fully disagree with this. Port 53 TCP has a much better chance at working these days than a random other newly assigned port. Not true. Port 53 is far more molested than "random"

Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

On Tue, 19 Aug 2014, Hosnieh Rafiee wrote: Still the nodes are in processing the hello client exchange and the encryption was not happened. As you explained in your draft, opportunistic security is in use. In other words, the server might not have certificate that is signed by a CA. In this c

Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

On Tue, 19 Aug 2014, Hosnieh Rafiee wrote: Data integrity is different than authentication. I am not talking about data integrity. If you can verify the data integrity of a node, it doesn't mean that it is authenticated. DNSSEC, at the moment is unable at the moment to protect his last mile a

Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

On Tue, 19 Aug 2014, Jacob Appelbaum wrote: Sure, let's be explicit. Proposed addition to the policy section: If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53. I'm not a fan of making it possible for an

Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

On Tue, 19 Aug 2014, Paul Hoffman wrote: I wonder this 'MUST' may be too strong (or I don't fully understand the sense of this MUST). Since the upstream recursive resolver may or may not support the TLS extension, the DNS forwarder may end up giving up the resolution altogether. But depending

Re: [dns-privacy] Summary of the thoughts about DNS privacy

resolver 2 Setup a VPN to a validating resolver you trust Both are out of scope for this draft. [Paul Wouters already explained that it makes no sense to authentify a DHCP-obtained resolver - since DHCP itself is not secure. You authentify hard-wired resolvers only.] :-) and my answer was that

Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

On Wed, 20 Aug 2014, Jacob Appelbaum wrote: Paul - perhaps this suggests that all stub and recursive resolvers should log keying information, even if it isn't used for validation/authentication/etc? That is one "out of band" authentication mechanism called TOFU (trust on first use) or LOF (Lea

Re: [dns-privacy] WG Review: DNS PRIVate Exchange (dprive)

On Mon, 6 Oct 2014, Olafur Gudmundsson wrote: My concern is about qname minimization: where will it fit here? (It's useless for the stub<->resolver communication) Stephane is right the, when I read the current draft charter all I got out of it was channel protection thus I assumed that query

Re: [dns-privacy] DNScurve limits (Was: Agenda time.

On Mon, 13 Oct 2014, Paul Hoffman wrote: Ummm, aren't we forgetting what is for many the much larger cons: * The nameserver has to do a Diffie-Hellman key agreement with every relying party, hugely increasing the CPU load. * The private key must be online all the time. * The private key must b

Re: [dns-privacy] DNScurve limits (Was: Agenda time.

On Mon, 13 Oct 2014, Phillip Hallam-Baker wrote: I think we can maybe clarify the charter a little here. Protecting the integrity of the messages between the stub and the resolver should be a requirement for any spec. Yes. But authenticity of the authoritative zone data is a completely sepa

Re: [dns-privacy] DNScurve limits (Was: Agenda time.

On Mon, 13 Oct 2014, Phillip Hallam-Baker wrote: DNSCurve was originally proposed to do a rather different job and it is actually better at that job than DNSSEC in my opinion. I agree that DNSSEC sucks at the job it is not supposed to do :) I would expect that anyone taking up DNSCurve and p

Re: [dns-privacy] DNScurve limits (Was: Agenda time.

On Tue, 14 Oct 2014, Mukund Sivaraman wrote: Will you explain why stub-resolver communication cannot be secured with the concepts in DNSCurve? The NS record would not apply, but I don't see anything in the packet formats itself that would make it useless. dnscurve is based on talking to the cr

Re: [dns-privacy] There is not only encryption in life (Was: DNScurve limits (Was: Agenda time.

On Mon, 20 Oct 2014, Stephane Bortzmeyer wrote: On Tue, Oct 14, 2014 at 10:04:14AM -0400, Paul Wouters wrote a message of 80 lines which said: And all the mentioned proposals for dns privacy already include encryption in one way or the other. I clearly disagree. At least two other

Re: [dns-privacy] DNScurve limits (Was: Agenda time.

On Mon, 20 Oct 2014, Stephane Bortzmeyer wrote: I disagree here. The work to "port" DNScurve to the stub-to-resolver link has already been done. It is called DNScrypt . It is actually deployed This is just a simple VPN

Re: [dns-privacy] The case for both ends of 'end-to-end'

On Thu, 24 Oct 2014, D. J. Bernstein wrote: I've never proposed "eliminating recursives" (caches). What I propose is complete _decentralization_ of the caches: you run your own trusted DNS cache on your own laptop/smartphone/etc., talking directly to the authoritative DNS servers---preferably wi

Re: [dns-privacy] The case for both ends of 'end-to-end'

On Thu, 23 Oct 2014, Watson Ladd wrote: With a modern browser, these two are pretty much the same thing due to in-application caching. So for the discussion on feasability of infrastructure, the argument is moot. Decentralising caches could actually be worse for dns privacy, as your query no lo

Re: [dns-privacy] Consensus and Compromise

On Thu, 13 Nov 2014, Hugo Connery wrote: 2. Trust between clients (stubs) and recursive resolvers Whether the communication to the recursive resolver is encrypted or not the resolver itself knows all queries (data and metadata). There is an implicit trust relationship between the client and

Re: [dns-privacy] DNS over TLS

On Tue, 11 Nov 2014, Stuart Cheshire wrote: I’m unable to attend the DPRIVE meeting in person because it overlaps with TAPS. I see on the agenda discussion of items like Private DNS and DNS over TLS. A historical note: Apple’s Back to My Mac service uses DNS over TLS to provide confidentialit

Re: [dns-privacy] draft-wijngaards-dnsop-confidentialdns and DDoS

On Thu, 19 Mar 2015, W.C.A. Wijngaards wrote: Could perhaps a different algorithm, like ED25519, provide better performance, and would that performance then be adequate? Different algorithms differ in performance how much? A factor 2? Maybe 10? Compared to a botnet, I don't think that it is ve

Re: [dns-privacy] draft-wijngaards-dnsop-confidentialdns and DDoS

On Fri, 20 Mar 2015, Watson Ladd wrote: What's wrong with DNScrypt? It's just a preconfigured new VPN protocol where the clients need to know the public key of this new VPN protocol provider to setup a VPN limited to "DNS"Curve packets. - It is incompatible with IETF VPN protocols (IPsec/IKE,

Re: [dns-privacy] Starting call for adoptions for "the 3 documents"

On Mon, 13 Apr 2015, Daniel Kahn Gillmor wrote: i think most people consider DHCP configuration to be at best minimally useful for DPRIVE -- it leaves you vulnerable at network connection time, but then protects you against subsequent attacks. *shrug* If you have an attacker on the last mile,

Re: [dns-privacy] Starting call for adoptions for "the 3 documents"

On Mon, 13 Apr 2015, Stephen Farrell wrote: I'm not sure if your point was meant to relate only to DHCP setting the DNS server IP, but if not then I have a question... Nope. On 13/04/15 21:21, Paul Wouters wrote: If you have an attacker on the last mile, there is nothing you c

Re: [dns-privacy] Starting call for adoptions for "the 3 documents"

On Mon, 13 Apr 2015, Daniel Migault wrote: Just for information, what are the technical reasons IPsec has not been considered at all for providing DNS privacy. People can already use an IPsec VPN and a remote DNS server without anything new from IETF? I think additionally, IPsec has a higher

Re: [dns-privacy] Considering IPsec

On Mon, 13 Apr 2015, Daniel Migault wrote: Just for information, what are the technical reasons IPsec has not been considered at all for providing DNS privacy. People can already use an IPsec VPN and a remote DNS server without anything new from IETF?   I do

Re: [dns-privacy] Starting call for adoptions for "the 3 documents"

On Tue, 14 Apr 2015, Stephen Farrell wrote: I wonder if the last mile concept is what we really want. Hmm, you are right. I guess we use "last mile" as a short hand. The two situations really are: 1) a remote DNS server for which we have a public key and can authenticate and encrypt with. 2)

Re: [dns-privacy] Considering DHCP

On Tue, 14 Apr 2015, Zhiwei Yan wrote: Hi, all, Then why not consider the DHCP? DHCP can support client authentication and can be used to configure the RS key on the authenticated client. Do you think this will help? How do you know the DHCP server is not a rogue attacker? How does the syste

Re: [dns-privacy] DPRIVE over UDP or TCP

On Sun, 26 Apr 2015, Watson Ladd wrote: If what we end up with is doing the same crypto operations as DNSCrypt, but with the extra complexity of managing connections (opening, closing, resuming, etc), what is the advantage? I've said this before.. My understanding of dnscrypt is that it i

Re: [dns-privacy] Preliminary Minutes Posted

On Sat, 25 Jul 2015, Tim WIcinski wrote: The rough consensus in the room was to request an early port allocation request; and to start with a new port directly. I thought that at least one of these had a third hum option that was not insignificant (although not as strong as t

Re: [dns-privacy] Early port allocation request for dns-over-TLS

On Thu, 13 Aug 2015, Joe Touch wrote: Joe Abley reminded me off-list that the service name for DNS is "domain", so my suggestion for the name for this new assignment would then be "domain-s". Why? Just let the "domain" reference die please, don't build on it. dnstls or so seems fine to me :P

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

On Tue, 3 Nov 2015, Tim Wicinski wrote: This starts a Call for Adoption fordraft-mayrhofer-edns0-padding I support the adoption by DPRIVE and will review it. The draft is available here: https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/ Paul _

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On Wed, 18 Nov 2015, Daniel Kahn Gillmor wrote: So i think that we should still say that a packet sender MUST pad with all-zeros for this draft, even though a recipient MUST NOT reject a query or response just because it a non-zero octet in its padding. In addition to compatibility with future

Re: [dns-privacy] Deployment issues

On Thu, 2 Jun 2016, Hugo Maxwell Connery wrote: so, lets get 8.8.8.8 running TLS DNS as a push. Hang on, they are a sruveillence/advertising business! No problem, it is just they who can surveill. It still makes sense to reduce the number of people that can read your DNS requests, just like

Re: [dns-privacy] Deployment issues

On Fri, 3 Jun 2016, Christian Huitema wrote: It still makes sense to reduce the number of people that can read your DNS requests, just like it makes sense to use https to google.com. Yes. And we have an interesting issue with the size of the service. In theory, anybody could set up a recursive

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

On Fri, 10 Jun 2016, Stephane Bortzmeyer wrote: Kim-Minh Kaplan reminded me I forgot the most obvious one: using the X.509 security model. Certs for authoritative name servers, signed by regular CAs, with the IP address of the server in the Subject Alternative Name. It seems foolish to me to m

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

On Fri, 10 Jun 2016, Stephane Bortzmeyer wrote: * publishing keys in the DNS, secured with DNSSEC (as in DANE), which raises an interesting bootstrap problem, Ohhh I forgot about that. I should have coffee before making up crypto schemes (and before I suggest adding a new DS key type :) Paul

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile

In favour of adoption Sent from my iPhone > On Nov 27, 2016, at 08:33, Warren Kumari wrote: > > Reminder -- this CfA concludes on Dec 2nd. > > W > >> On Sat, Nov 19, 2016 at 2:48 PM, John Levine wrote: >> In article you write: >>> I support the adoption of this document, knowing that there

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

On Tue, 13 Dec 2016, Stephane Bortzmeyer wrote: IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec may have problems traversing NAT. It is also usually implemented by the kernel, which may cause deployment issues. I *want* IPsec to be an option here, but realistically I don't

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

On Tue, 13 Dec 2016, Paul Hoffman wrote: IPsec will always have worse characteristics for DOS than DTLS, and probably worse than TLS. [citation needed] Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns

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

On Wed, 14 Dec 2016, Paul Hoffman wrote: Exactly. Further, you have to negotiate in IPsec which ports and addresses within the "range of one target address" the client has access to, and that (you would think simple) negotiation has proven too difficult for some IPsec developers in the past.

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

On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy wrote: > > +1, DNSSEC itself is susceptible to active attacks and needs a secure channel > to protect from an active attacker. What active attacks is DNSSEC vulnerable to? And how does that not affect TLS? Paul > > -Tiru > > From: dn

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

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: An active attacker can drop DNS messages with DNSSEC records The same attacker can block TLS to 8.8.8.8 set the CD bit in the DNS query, AD bit in the DNS response That will do nothing to validating DNS servers, as they don't use those

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

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Just to be clear. DNSSEC provides authentication of data. TLS provides privacy of data. Both are needed so I am against this proposed change

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

On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote: Date: Mon, 30 Oct 2017 11:08:35 From: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org To: Sara Dickinson Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement On Mon

Re: [dns-privacy] [Ext] Re: [Editorial Errata Reported] RFC7858 (5375)

> On Jun 1, 2018, at 16:28, Brian Haberman wrote: > > >> >> I'm pretty sure it was correct at publication time (I think I checked it); I >> suspect they changed it. Either way, is should be marked as Verified. >> > > If the wayback machine is correct, then you are correct as well. It > loo

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

On Mon, 16 Jul 2018, Tony Finch wrote: Ben Schwartz wrote: (I suspect they might object to the multi-query session semantics, or the wide variety of TLS ClientHellos, but I don't actually know.) Multi-query sessions are much less objectionable than one-shot sessione: you amortize both the s

Re: [dns-privacy] Recursive Resolver Operator Perspective

> On Jul 25, 2018, at 12:37, Paul Hoffman wrote: > Some resolver operators have recently spoken of a new use case: giving > assurance of results in unsigned zones, and assurance of child NS and glue > records in signed zones. This use case is not about privacy. That should not be considere

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

On Wed, 12 Sep 2018, Willem Toorop wrote: Op 12-09-18 om 13:57 schreef Ilari Liusvaara: On Wed, Sep 12, 2018 at 12:02:56PM +0100, Tony Finch wrote: The reason for wanting to include the NS targets' TLSA records in the glue is so that the resolver can immediately connect over DoT with authenti

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

On Wed, 12 Sep 2018, Tony Finch wrote: Then use RFC 7901 DNS chain queries (or the hopefully soon tls-dnssec-chain TLS extension) RFC 7901 doesn't work when asking authoritative servers because they don't have a copy of the chain. You can set the start of the chain to the zone, so as long as

Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

With dnssec yes. The publisher is then the only one in control. This is why it is so problematic that the browsers have pushed back instead of working with the dns people. When personal VPNs became a thing, it didn’t take long for 90% of the VPN “apps” to become malicious, redirecting DNS, mon

Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

On Nov 22, 2018, at 19:29, Barry Raveendran Greene wrote: > > > > > The “trade off” to move the DNS architecture away from residents to privacy > is going to get people killed. Since ISPs are doing this themselves already at large scale (use 8.8.8.8 instead of their own), I find the argume

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

On Fri, 30 Nov 2018, Bill Woodcock wrote: And as an operator of recursive and authoritative servers, I’d very much like us all to listen to what Karl is going to say. I suspect Stéphane will be interested as well. :-) Why wait ? Let's hear what he has to say on the list beforehand, so we c

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

On Fri, 30 Nov 2018, Hollenbeck, Scott wrote: Why wait ? Let's hear what he has to say on the list beforehand, so we can discuss on the list and if needed during the interim. It would be a better use of our voice-to-voice time. Here's what's been shared with the list already: https://mailarch

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

On Fri, 30 Nov 2018, Hollenbeck, Scott wrote: times have changed, and it deserves another look, but some note that says "If running out of resources, drop the encryption and serve DNS data in the clear might be needed". Ideally in a way that querying clients that want to insist on privacy can ba

Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

On Fri, 30 Nov 2018, Paul Hoffman wrote: I am not sure I see a need for a different TLS/DTLS profile compared to regular (web) based (D)TLS connections. What do you or Karl think would be different? (D)TLS is not the only option. Using message security instead of connection security would eli

Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

On Wed, 5 Dec 2018, Brian Haberman wrote: While MLS is still in its infancy, it is designed for many-to-many communications. That may be beneficial when we are talking about authoritative servers using anycast. MLS is about authenticated (group) chat. In this case, the is a big need for the qu

Re: [dns-privacy] Alternative signalling propsals

On Fri, 14 Dec 2018, Warren Kumari wrote: One of the stated reasons for browsers not doing DANE / TLSA was having to wait for the TLSA record to come back before you can connect.  "Ah! Fine..", says I, "Just do these in parallel -- you will get back the TLSA record at about the same time as th

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 IS

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

On Wed, 13 Mar 2019, Stephen Farrell wrote: Hmm. Not sure what to make of that. DNSSEC presumably makes it possible to detect interference, and yet RPZ (IIRC) calls for not changing DNSSEC-signed answers. I don't get why an inability to change is ok for the RPZ/DNSSEC context but not for DoH.

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

On Tue, 12 Mar 2019, Paul Vixie wrote: i don't like the chinese government's rules for the great firewall. so, i keep my visits to that otherwise-great country short. this hurts me, and maybe hurts them also. but, it's their country, and i will obey their laws when i am using their network. and

Re: [dns-privacy] Concerns around deployment of DNS over HTTPS (DoH)

On Wed, 13 Mar 2019, Kenji Baheux wrote: I'm involved with Chrome's DoH efforts. Our motivations in pursuing DoH in Chrome is to offer our users a better user experience: Hopefully, some performance wins. Tentative plans: We are considering a first milestone where Chrome wou

Re: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626-bis-02.txt

On Wed, 27 Mar 2019, Brian Haberman wrote: All, This is a call to judge consensus on adopting: Title : DNS Privacy Considerations Authors : Stephane Bortzmeyer Sara Dickinson Filename: draft-bortzmeyer-dprive-rfc7626-bi

Re: [dns-privacy] Some additional signalling ideas

On Sun, 31 Mar 2019, Watson Ladd wrote: Please rip these ideas to shreds: 1) An extra bit in a response for "you could have asked over TLS" Too late, you already lost your privacy. 2) An extra field when looking up the nameserver for "you can ask that server over TLS" Where would this fie

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

On Tue, 29 Oct 2019, Paul Hoffman wrote: I have to say that I'm pretty surprised by the idea that TLS in this context should behave any differently than TLS in application layer contexts, and I'm a little concerned about having configuration options for this that amount to "ignore errors of ty

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

On Tue, 29 Oct 2019, Stephen Farrell wrote: I had a quick read and support adoption. There's work to be done but doing it in the WG seems correct to me. I'm not sure I would agree. In a way, dnsop seems more appropriate to me. Sure it is about encryption, but to me dprive feels more to be for

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

> On Oct 29, 2019, at 20:44, Ben Schwartz > wrote: > > > > > > My understanding is that one has no choice but to trust the parent zone, even > with DNSSEC. One can limit the trust severely, which is what https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ does. Paul _

Re: [dns-privacy] [Ext] Threat Model

> On Nov 3, 2019, at 07:27, Warren Kumari wrote: > >> Can you expand on this? Is the convention that if I see x-dot.example.com, >> then I should expect DoT? > > Yup, that’s it exactly. > > As a DNS person, encoding semantics into the name makes me twitch It should do more than cause a twit

Re: [dns-privacy] [Ext] Threat Model

On Mon, 4 Nov 2019, Tony Finch wrote: Subject: Re: [dns-privacy] [Ext] Threat Model Paul Wouters wrote: The right way to do this is a DNSKEY flag, which is protected by the signed DS at the parent. Similar to draft-powerbind for the delegation-only domain. That's per-zone, though, wh

Re: [dns-privacy] [Ext] Threat Model

On Mon, 4 Nov 2019, Brian Dickson wrote: The names of the servers (and certificate management) would be orthogonal to the signaling of DoT support. I would expect the TLSA records would be per-server and orthogonal to the per-zone signaling of DoT support. Again, that would be russian roulett

Re: [dns-privacy] [Ext] Threat Model

On Tue, 5 Nov 2019, Warren Kumari wrote: $ dig ns a.example.com ;; ANSWER SECTION: a.example.com. 42923 IN NS ns1-dot.nameservers.example. a.example.com. 42923 IN NS ns2.nameservers.example. Now, if you cannot reach ns1-dot.nameservers.example, whether you fall back to ns2.nameservers.example i

Re: [dns-privacy] [Ext] Threat Model

On Tue, 5 Nov 2019, Warren Kumari wrote: Because then I need to probe them on 853 and wait N before trying on port 53, or I will only get any sort of protection for name-servers which I’ve spoken to recently enough that I have them in cache — that works for e.g: ns1.google.com, but not ns0.noh

Re: [dns-privacy] [Ext] Threat Model

> On Nov 6, 2019, at 04:24, Ralf Weber wrote: > > >> 4: without expecting everyone to support DNSSEC. > Really. I can not see how we design something new that does not take DNSSEC > into account. Indeed. The longer we treat DNSSEC as optional, the longer we will be faced with adoption proble

Re: [dns-privacy] [Ext] Threat Model

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 applic

Re: [dns-privacy] [Ext] Threat Model

> On Nov 8, 2019, at 17:06, Bob Harold wrote: > > > I hate to admit it, and this is a little off topic, but my resolvers are not > (yet) validating. Then your resolvers’ configuration is years out of date. All resolvers these days ship with validation enabled. > Is there a setting that will

Re: [dns-privacy] [Ext] Threat Model

> 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 > dur

Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN

On Fri, 13 Dec 2019, Erik Nygren wrote: Linking ALPN and port defeats the purpose of ALPN. Indeed. The main driving factor for having an ALPN token is for cases when there is a desire to configure dot and doh to share a port (especially 443) for some use-case. But take into account that Do

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Tue, 19 May 2020, Peter van Dijk wrote: The draft is managed on GitHub in .md format at https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin This is . interesting. We first added the KEY RRTYPE in the 1990's to allow generic public keys

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Sat, 23 May 2020, Peter van Dijk wrote: As I remarked in my reply to Jeremy, I spent quite some time thinking about how to do the signalling&pinning with actual TLSA records, but I never ended up with a satisfactory solution. But I don't think your current solution is satisfactory either. I

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Sun, 24 May 2020, Peter van Dijk wrote: On Sun, 2020-05-24 at 13:43 -0400, Paul Wouters wrote: But I also don't see the gains of abusing DNSKEY, because you already need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key, and then you already lost your privacy. The draft

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Tue, 26 May 2020, Peter van Dijk wrote: So, while my first though was same as Paul’s - this is abuse… I came to conclusion, it actually isn’t. That said - I think this needs some modifications: 1. Bit 7 of the Flags fields needs to be 0. Definitely - it is not explicit but the examples i

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Wed, 27 May 2020, Ben Schwartz wrote: I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if it would help.  This use case is important enough to drive deployment. If people really want to avoid doing an extra

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Wed, 27 May 2020, Petr Špaček wrote: - I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you see any evidence it is going to change? The draft has been resubmitted for the ISE stream (not TLS WG) as draft-dukhovni-tls-dnssec-chain Stubby already implements it. We do

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Wed, 27 May 2020, Peter van Dijk wrote: DoT authoritatives would need to keep both the old and new certificates on hand during the transition keys, not certificates I would not rule out that people want to run this using a CA chain. Limiting the signaling to EE-certs or pubkeys is n

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Thu, 28 May 2020, Petr Špaček wrote: Is there any indication that TLS libraries are going to implement this? (Unmerged patches do not count!) I thought "indication" to implement would be uhm, unmerged patches? Otherwise, it would be implemented already and you wouldn't need any more indica

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

er this DoT channel. Where would we gain much by using RFC 7901 Query Chains or tls-dnssec-chain? Paul On Thu, May 28, 2020 at 9:44 AM Shumon Huque wrote: On Thu, May 28, 2020 at 5:33 AM Stephen Farrell wrote: On 28/05/2020 02:55, Paul Wouters wrote: > But we are unf

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Thu, 28 May 2020, Ben Schwartz wrote: Using tls-dnssec-chain would save a roundtrip.  So would putting an SPKI pin along with "ns0.nohats.ca" in the DS record.  I think both are reasonable optimizations, and should be optional*. You suggest a hack on top of a hack, to save 1 RTT for a reco

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Fri, 29 May 2020, Peter van Dijk wrote: On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote: It would make everything a LOT cleaner and we got no bogus DNSKEY records to ignore in our DNSSEC validation path. What bogus DNSKEY records? It really all depends on what registry systems you

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

Note for DNSKEY algorithm, we could use 253 or 254: https://tools.ietf.org/html/rfc4034#appendix-A.1.1 A.1.1. Private Algorithm Types Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the s

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Fri, 29 May 2020, Peter van Dijk wrote: - Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our DS request I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no registry does this. Yes, hopefully, they will limit themselves to ch

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Fri, 29 May 2020, Peter van Dijk wrote: On Wed, 2020-05-27 at 21:47 -0400, Ben Schwartz wrote: On Wed, May 27, 2020 at 9:27 PM Paul Wouters wrote: Personally, I think it would be cleanest if we use the DS to signal the DoT nameserver only by FQDN. I agree.  This is the

Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Fri, 29 May 2020, Peter van Dijk wrote: I'm not even sure what my question is, so let's try this: if a malicious parent has the ability to publish a malicious DS record, why wouldn't that parent also change the NS records in some subtle way? Then the real client side CDS becomes invisible. I

[dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Wed, 3 Jun 2020, Peter van Dijk wrote: We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So flags are out. I think it would be simplest to alloc

Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Tue, 9 Jun 2020, Robin Geuze wrote: So lets start at the beginning, why do we want to encrypt the communication between then resolvers and the authoritatives in the first place. There are two main reasons for encrypting things. One is authentication. I disagree. Setting up a TLS connection

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

On Jun 10, 2020, at 07:55, Shumon Huque wrote: > >  > > The more I think about all the privacy leaks that have to be plugged at > the DNS and application layers, Tor increasingly looks better as a > general purpose solution (either as a network to funnel DNS messages > through, or even better,

  1   2   >