Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
Ray Bellis writes: > Serve stael must not become a vector whereby malware can keep its C > systems artificially alive even if the parent has removed the C domain > name. I wholeheartedly agree with this ideal, and am very open to considering text improvements. The document already has guidance on this point, but it is admittedly in a considerations section and not in standards action, and is a weaker "SHOULD" versus "MUST" right now. Would the WG prefer that a line like this be put into the Standards Action section? When no authorities for a name are able to be reached, the resolver MUST attempt to refresh the delegation. I like the basic idea but am a little stuck on the wording because of the endless loop it implies. This is probably why it appears as "SHOULD" already (but I honestly don't remember, so there's that). It seems to me that the risk is very low, even as currently written in the draft. Not only do I have a lot of confidence in the implementers of the most widely used resolvers in the world, as they're right here participating too and have in the past shown good conscientiousness in this area, but the practical attack is still hard to make meaningful. If "the parent has removed the C domain name" as you said, serve-stale shouldn't even kick in. NxDomain, problem solved. Various other scenarios come to mind, even with obstinate parents that won't remove the delegation and the zone's NSs have gone dark, but those scenarios have other possible remedies. And fast flux using long TTL NS RRsets are an issue no matter whether serve-stale is in play or not. So text regarding refreshing delegations could be given even more words to describe backoff intervals and such, but to what end? What's the scenario? And wouldn't it be handled better by reviving resimprove to talk about the generalized problem? (To be clear, I'm quite okay with politely being shown that I'm wrong and there is a vector by which serve-stale becomes uniquely interesting, and would certainly endeavour to make sure it is addressed.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
> On Mar 25, 2019, at 3:47 PM, Olli Vanhoja wrote: > >> Section 3.2. discussion: Unless there's a potential benefit to non-apex >> ZONEMD records that I'm not seeing, I think it makes sense to forbid them. >> Was there a particular thing that could be enabled by that, which prompted >> the suggestion? > > I agree with this. I believe it would create unnecessary complexity. > For example, which records would such a digest cover? Would the apex > record cover also the records covered by this subdigest? Matt / Olli, I'm not aware of anything that could be enabled by non-apex ZONEMD records. My preference would be to forbid non-apex ZONEMD records. I guess my concern was just that it means implementors need to check for this and treat the RR type somewhat specially, as they do for SOA and maybe a couple other RR types. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
bert hubert writes: > I too object. This is partially due to the apparently unresolved IPR issue > from Akamai, who are known not to be shy asserting their IPR. This is definitely a problem. Even though Akamai had previously agreed to specify under what IETF-acceptable terms the IPR would be made available, it clearly hasn't yet specified them. I've contacted them to get a timeline on when the legal department can take care of this, and the first order response is that the DNS team is trying to get the ball rolling again with legal this week. > My secondary objection is that the draft contains an example > implementation that then however uses normative words. This leads to > pain with operators demanding serve-stale compliance. Example > algorithms should clearly be examples and not tell us what we SHOULD > do. As previously noted in this very thread, at least one of the authors, Puneet, agrees with you. When I wrote the text that way it was because of the also not-unreasonable viewpoint that if someone were to be implementing the example then the text could be considered normative as to how to do that. It's even softened by having no MUSTs at all, just SHOULD. In addition, I'm dubious as to the claim that people would cause meaningful pain to demand compliance with an example, and not be adequately refuted when it is pointed out to them that it is a clearly marked as an example. That said, since I had waffled on it myself at time of composition and I don't actually have a very strong feeling about it, in the end wouldn't fight over downcasing it. Yet I think it should be settled at a level above dnsop because ultimately it's an issue that should be consistent across IETF documentation. Unless there's already an explicitly stated IETF policy about this, and not just ad hoc past cases to point to, I think it is best to sort out with the RFC editor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
Paul Vixie writes: > i would withdraw that objection if this draft incorporates section 2 of > https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit: I always liked resimprove. Warren and I were talking about it, and if you would like we'd be quite happy to pick it up and get it moving in dnsop. This document already has text, however, for refreshing the delegation and I don't believe it really needs to much detail as to what that means. "Delegation Revalidation Upon NS RRset Expiry" is an issue orthogonal to serve-stale, and in fact most often applies when serve-stale isn't even being triggered; it's a regular occurrence under normal operations. Ballooning the standards action section here to nearly three times its existing size is unnecessary bloat. Please let us know if you'd like us to take up the charge for resimprove. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2845bis draft
Peter J. Philipp wrote: > > I'm in contact with the original RFC 2845 authors for clarifications > on what is meant in section 4.4 for the meaning of "Prior MAC > (running)". In the bis draft this is in section 6.4 and seems > unchanged. I'm having a hard time understanding this as an > implementor, this is an area that needs clarification I believe. Actually, looking at this now, the definition of the digest components in this section is even more unclear: | Prior Digest (running) | DNS Messages (any unsigned messages since the last TSIG) | TSIG Timers (current message) I am probably overthinking this, but the second item can be read as if it only contains the messages sent unsigned so far and does _not_ include the message currently being processed. This seems a bit unlikely, but then, there must be a reason why it says "any unsigned message" and not simply "any message". I guess I’ll find out what is exactly meant when I am going to test my implementation. But either way, this could perhaps be more clear? Kind regards, Martin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
On Mon, Mar 25, 2019 at 04:30:01PM +0100, Ray Bellis wrote: > > > On 25/03/2019 16:08, Puneet Sood wrote: > > > you mean lots of changes or lots of agreement with the quoted text? > > They mean very different things. > > I was agreeing with the quoted text - I believe that any serving of > stale records must be predicated on the presence of a valid delegation > from the parent zone. > > Serve stael must not become a vector whereby malware can keep its C > systems artificially alive even if the parent has removed the C domain > name. +1 Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
It seems like SACK would make the problem less bad in theory, but wouldn’t eliminate the problem. With DNS-over-DTLS, if a packet is lost, the next packet still gets an immediate answer, because DTLS is a datagram protocol, not a stream protocol. The retry strategy for DNS-over-DTLS would be the same as DNS-over-UDP, once the Diffie-Hellman shared key has been derived. So assuming you are using this to communicate to a resolver, there would be an initial handshake that’s extra compared to DNS-over-UDP, and then it would just be DNS-over-UDP until such time as re-keying is needed. > On Mar 25, 2019, at 5:13 PM, Tony Finch wrote: > > Ted Lemon wrote: >> On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: >>> If I understand it correctly, DTLS leaves MTU and fragmentation up to the >>> application protocol. The DNS has horrible packet size problems, so it >>> needs a lot more help than DTLS provides. QUIC is much better. >> >> Indeed. My point was simply that this avoids ordering problems, just as >> QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is >> great, but based on what I’ve been seeing, quite a lot, and probably not >> appropriate for a lot of use cases where DNS-over-DTLS would do just >> fine. > > It isn't so much ordering that is the problem, but not delaying answer B > when answer A suffers packet loss. I'm kind of curious about what the > relative trade-offs might be between DoQ and DoT with a decent SACK > implementation, when there is not much latency between the client and the > resolver. DNS-over-DTLS will need its own application layer retry > strategy. I kind of prefer the idea of DNS being able to re-use a good > off-the-shelf transport protocol rather than doing its own thing. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ted Lemon wrote: > On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: > > If I understand it correctly, DTLS leaves MTU and fragmentation up to the > > application protocol. The DNS has horrible packet size problems, so it > > needs a lot more help than DTLS provides. QUIC is much better. > > Indeed. My point was simply that this avoids ordering problems, just as > QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is > great, but based on what I’ve been seeing, quite a lot, and probably not > appropriate for a lot of use cases where DNS-over-DTLS would do just > fine. It isn't so much ordering that is the problem, but not delaying answer B when answer A suffers packet loss. I'm kind of curious about what the relative trade-offs might be between DoQ and DoT with a decent SACK implementation, when there is not much latency between the client and the resolver. DNS-over-DTLS will need its own application layer retry strategy. I kind of prefer the idea of DNS being able to re-use a good off-the-shelf transport protocol rather than doing its own thing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-01.txt
This update contains a few minor wording changes to try to make the applicability clearer. We've also added Peter van Dijk from PowerDNS as a co-author. Ray Forwarded Message Subject: New Version Notification for draft-bellis-dnsop-edns-tags-01.txt Date: Mon, 25 Mar 2019 07:00:14 -0700 From: internet-dra...@ietf.org To: Ray Bellis , Peter van Dijk , Alan Clegg A new version of I-D, draft-bellis-dnsop-edns-tags-01.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-edns-tags Revision: 01 Title: DNS EDNS Tags Document date: 2019-03-25 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-edns-tags-01.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-edns-tags/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-edns-tags-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-edns-tags Diff: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-edns-tags-01 Abstract: This document describes EDNS Tags, a mechanism by which DNS clients and servers can transmit an opaque data field which has no defined semantic meaning other than as previously agreed between the client and server. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
On 25/03/2019 16:08, Puneet Sood wrote: you mean lots of changes or lots of agreement with the quoted text? They mean very different things. I was agreeing with the quoted text - I believe that any serving of stale records must be predicated on the presence of a valid delegation from the parent zone. Serve stael must not become a vector whereby malware can keep its C systems artificially alive even if the parent has removed the C domain name. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: > If I understand it correctly, DTLS leaves MTU and fragmentation up to the > application protocol. The DNS has horrible packet size problems, so it > needs a lot more help than DTLS provides. QUIC is much better. Indeed. My point was simply that this avoids ordering problems, just as QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is great, but based on what I’ve been seeing, quite a lot, and probably not appropriate for a lot of use cases where DNS-over-DTLS would do just fine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ted Lemon wrote: > This is equally an argument for doing DNS over DTLS. This would give > similar performance to DoH over QUIC. If I understand it correctly, DTLS leaves MTU and fragmentation up to the application protocol. The DNS has horrible packet size problems, so it needs a lot more help than DTLS provides. QUIC is much better. Tony. -- f.anthony.n.finchhttp://dotat.at/ The Minch: Westerly 4 or 5, backing southwesterly 5 or 6, occasionally 7 later in north. Rough in far north and in far south, otherwise slight or moderate. Occasional drizzle. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
Reposting to the list what I shared with Richard Bennett earlier. The Google Public DNS privacy policy is at https://developers.google.com/speed/public-dns/privacy. Maybe I should have included a link to it in the earlier email. If you have comments on it, please share. We are following https://tools.ietf.org/html/draft-ietf-dprive-bcp-op and have commented on an earlier version. -Puneet On Sat, Mar 23, 2019 at 3:48 AM Richard Bennett wrote: > > I like it if you would kindly define “privacy” in the context of “a DNS > resolver that protects our users’ privacy.” Does that mean hiding their > lookups from ISPs who might want to enter the market for targeted ads while > using them for your company’s own purposes, or just protecting user queries > made over insecure public Wi-Fi networks from easy snooping? Because there > are better ways to do the latter than with a system that opts users into a > centralized resolver. > > RB > > On Mar 22, 2019, at 4:08 PM, Puneet Sood > wrote: > > Hello, > > There has been much discussion in the IETF lists over the impact of > using DNS-over-HTTPS (DoH) in a network. We would like to clarify the > Google Public DNS position on this topic. The post I am replying to is > particularly relevant since it makes some assumptions about the plans > of the Google Public DNS service. > > For future support of a RFC 8484 compliant service, we plan to do the > following: > * Serve RFC 8484 compliant DoH from the well known Google Public DNS > anycast IP addresses (e.g. 8.8.8.8) on the standard HTTPS port 443. > * Migrate our existing DoH services to the well known Google Public > DNS anycast IP addresses, including the beta version (at > https://dns.google.com/resolve) and IETF draft version (at > https://dns.google.com/experimental). > > The Google Public DNS anycast IP addresses are distinct from the IP > addresses used to host web content for Google properties. This will > allow operators to control access to the Google Public DNS DoH service > on their networks without impeding access to other Google services. > > For DoH implementers we want to ensure the same access to our > implementation whether it is a Google product (like the Chrome > browser) or a third-party product. To this end we aim to track IETF > work on standardized ways to detect DoH support by the system-selected > DNS resolver service (like > https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-02 > or https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01). > > As a core principle, Google Public DNS aims to provide a DNS resolver > that respects our users’ privacy. Towards that goal, we aim to provide > high quality implementations of various DNS transport mechanisms that > our users can use to reach the service. This includes the traditional > UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that > provide privacy for the user’s communication with a DNS resolver. > > -Puneet Sood > TL/Manager for the Google Public DNS team. > > PS: I am attending IETF 104 and will be available for face-to-face discussion. > > On Wed, Mar 20, 2019 at 2:40 PM 神明達哉 wrote: > > > At Wed, 20 Mar 2019 12:38:05 +0100, > Joe Abley wrote: > > Often as an industry we may discuss various solutions that are great for > oneself but don’t scale when looking at the big picture. > > > I think what we are seeing is the fundamental tension between privacy and > control. You need to give up some privacy in order to make the control > possible; you need to give up some control in order to afford privacy. > > > Some in this thread want certainty that they are able to exercise control, > e.g. for devices in their network. > > > Some in this thread want certainty that they can obtain privacy, e.g. for for > their device in any network. > > > [...] > > Thank you for the nice, concise summary. I think it's well-balanced > observation of where we are. (I'm so glad I can finally see a > constructive post after seeing a common pattern of boring IETF > discussion, where people with different opinions just keep stating > their views without making any real progress:). > > Seems to me that there's a middle ground within sight here. > > Standardise this privacy mechanism, and specify (with reasoning) that it > should be implemented such that the existence of the channel (but not the > content) can be identified as distinct from other traffic by third parties. > Maybe specify use of a different port number, as was done with DoT. > > > I see that those who want to exercise control can live with this (or > at least using a different set of IP addresses for DoH servers than > those for other ordinary web services). But I'm not so sure if that's > acceptable for the other group.. In that sense I'm curious whether > some big possible DoH providers are now willing to accept this middle > ground. If my memory is correct the longer term plan at Google (and > maybe also Clouldflare?) is to provide
Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
On Mon, Mar 25, 2019 at 2:54 PM Matthew Pounsett wrote: > > > > Section 3.2. discussion: Unless there's a potential benefit to non-apex > ZONEMD records that I'm not seeing, I think it makes sense to forbid them. > Was there a particular thing that could be enabled by that, which prompted > the suggestion? I agree with this. I believe it would create unnecessary complexity. For example, which records would such a digest cover? Would the apex record cover also the records covered by this subdigest? > In 3.4.1 would it make sense to include a sentence explaining the catch-22 > that would result if the RRSIG covering the ZONEMD record were included in > the digest? > > In section 4, I suggest replacing all of the instances of "provably > [un]signed" with "provably [in]secure". To me, a zone is provably signed if > it has DNSKEYs and RRSIGs that validate from those DNSKEYs. What the draft > is interested in is whether those signatures link up to a trust anchor > somewhere, and the term for that is "secure".. But maybe there are > definitions somewhere that I haven't read that make "signed" and "secure" > equivalent, which would make this a silly suggestion. Does it matter for this feature that the trust chain verifies? If so, does it mean that it's provably secure? Maybe the private key was leaked but not yet revoked, thus it's provably properly signed and verifies, but it's not provably secure. Perhaps we could add some wording to define what we mean by that (either). > Section 2 discussion: I was initially ambivalent about whether multiple > ZONEMD records should be allowed with different digest types. Having gone > back and re-read some of the discussion, I'm persuaded that it would be > beneficial to allow multiple digest types to be used on the same zone > instance. I think we'd want to have a bunch of discussion about the details > in order to keep code complexity under control, though. > Section 5 discussion: I can't remember if I commented on this bit before or > not, but just in case.. I support keeping the reserved field. It seems to me > that if we have to get a new type for an incremental-friendly version of > ZONEMD that we're going to have implementation fragmentation and a migration > issue. Especially if we don't allow multiple ZONEMD records, I can imagine > it being difficult to have both in the zone at once, and that it could be > hard to specify what should happen if an operator wants to migrate from > ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone > support > It think it would make sense to allow multiple ZONEMD records at the *apex* level. That would allow one to support multiple different hash functions as well as to migrate to a new hash function without breaking the existing clients. I'm not sure if there would be any benefit of supporting multiple functions initially. Would someone possibly say they need function x to be supported for perf reasons? Or perhaps just that some other function x is natively available in some system but the SHA384 isn't. Like I said before, I'm already operating a system that is internally doing something very close to this. The major difference is just that I'm using a different hash function but that's only because this draft didn't exist when I made that decision and I think SHA384 would be better fit. I think, I will try to compare the differences soon(ish) and hopefully make my implementation compatible with this draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ian Swett wrote: > One way DoH may be faster than DoT in the near future is that DoH can go > over HTTP/3 via QUIC and avoid head of line blocking like Do53. It ought to be better to have native DoQ to eliminate the overhead of the http layer. Dunno whether this should use yet another port (all the obvious ones are already taken) or use ALPN. Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber: Northwest 6 or 7, occasionally gale 8 at first, decreasing 4 or 5. Rough or very rough, becoming moderate later. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
nusenu wrote: > > https works also without names it is just less common. It's difficult to get a certificate for an IP address. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne: Northwest 5 or 6, backing west 4 or 5, occasionally 7 at first in Forties. Rough, occasionally very rough at first in Forties, becoming moderate. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
On Wed, 13 Feb 2019 at 22:56, Wessels, Duane wrote: > The only change to this document since -05 is to note that ZONEMD has been > allocated RR type code 63 by IANA following an expert review back in > December. > I haven't reviewed this for a couple of revisions, so some notes here that don't apply to the new codepoint. :) . I've tried doing some searches of the discussion history to make sure I'm not raising points already addressed, but my apologies if I've missed something. Section 2 discussion: I was initially ambivalent about whether multiple ZONEMD records should be allowed with different digest types. Having gone back and re-read some of the discussion, I'm persuaded that it would be beneficial to allow multiple digest types to be used on the same zone instance. I think we'd want to have a bunch of discussion about the details in order to keep code complexity under control, though. Section 3.2. discussion: Unless there's a potential benefit to non-apex ZONEMD records that I'm not seeing, I think it makes sense to forbid them. Was there a particular thing that could be enabled by that, which prompted the suggestion? In 3.4.1 would it make sense to include a sentence explaining the catch-22 that would result if the RRSIG covering the ZONEMD record were included in the digest? In section 4, I suggest replacing all of the instances of "provably [un]signed" with "provably [in]secure". To me, a zone is provably signed if it has DNSKEYs and RRSIGs that validate from those DNSKEYs. What the draft is interested in is whether those signatures link up to a trust anchor somewhere, and the term for that is "secure". But maybe there are definitions somewhere that I haven't read that make "signed" and "secure" equivalent, which would make this a silly suggestion. Section 5 discussion: I can't remember if I commented on this bit before or not, but just in case.. I support keeping the reserved field. It seems to me that if we have to get a new type for an incremental-friendly version of ZONEMD that we're going to have implementation fragmentation and a migration issue. Especially if we don't allow multiple ZONEMD records, I can imagine it being difficult to have both in the zone at once, and that it could be hard to specify what should happen if an operator wants to migrate from ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone support ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
On Mar 24, 2019, at 07:42, Paul Hoffman wrote: > Greetings again. As y'all have seen over the past few weeks, the discussion > of where DNS resolution should happen and over what transports has caused > some people to use conflicting terms. As a possible solution to the > terminology problems, I am proposing a few abbreviations that people can use > in these discussions. I like the idea in general of trying to anticipate and avoid problems before they happen. However, I wonder in this case whether a lexicon is going to help. The problems with the conversation today (I would say) are more fundamental than terminology. It's long been my observation that finding a name for something has the potential to suck all the air from the room. The room we are in is perhaps stuffy enough already. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25/03/2019 10:41, Patrick McManus wrote: I've seen this confusion before, so I can clear it up! Ray is (I believe) referring to the flexible re-ordering of DNS request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less flexibility in granularity iirc). That addresses hol-blocking problems due to the time the server spends building replies. Ian is (I believe) referring to head of line blocking problems related to TCP's in-order delivery semantic and packet loss. TCP packet loss will delay the delivery of received packets if there are outstanding unreceived lower-numbered packets. If the data in these packets are unrelated (e.g. different DNS request/reply pairs) - that causes head of line blocking to the application. That's true of http/2 and RFC7766 (anything tcp based really). QUIC streams provide a mechanism for identifying which sequences actually need to have that dependency. DoH with H3 would use separate streams for separate requests (as different HTTP exchanges are inherently on different streams). Its a shame that the term hol blocking is used for both scenarios - it has caused a lot of confusion. hth Yes, that dh :) I was indeed talking about DNS message re-ordering, and wasn't aware of this particular distinction at the TCP layer itself when compared to QUIC. thanks, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
DoT and DoH seem fine. But maybe skip the acronym for Do53 - just call it conventional DNS or unencrypted DNS, or DNS over Port 53. Compared to RDoT/ADoT/DaT/DaO however, Do53 is the least offensive IMO. I don’t think you do much for clarity with RDoT and ADoT - seems mostly to be used because you want more acronyms. ;-) For RDoT this is the stub/client to recursive DoT link of the lookup chain. This is client-to-recursive (C2R DoT? Ha!), whereas ADoT is the recursive server performing recursion to a series of authoritative servers - recursion-to-authoritatives (R2A DoT? Acronym overkill achieved.) So I think those need some work. I find DaT and DaO rather confusing. I feel like you may be trying too hard on acronyms and these will become very difficult for others to understand. Really the difference is between network-assigned DNS, user-assigned DNS, and client-assigned DNS - so 3 separate primary use cases of assignment of your resolver. I would maybe focus on the difference between the manner of assignment/configuration and not worry too much (at least for now) over some sort of acronym, since it seems at this early stage of discussions that the acronym may cause more confusion that more straightforward (but longer) terms. I think you could also add definitions for Centralised (Recursive) Do53/DoH/DoT, as well as Distributed (Recursive) Do53/DoH/DoT. This refers to how widely distributed or centralized the group of operators of the recursives are or are not. I took a stab at that definition in my draft you could work from if you wish. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
This is equally an argument for doing DNS over DTLS. This would give similar performance to DoH over QUIC. On Mon, Mar 25, 2019 at 10:43 Brian Dickson wrote: > > > On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus > wrote: > >> >> >> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson < >> brian.peter.dick...@gmail.com> wrote: >> >>> >>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do >>> not believe anyone has proposed explicit downgrade triggers. >>> >> >> that's the downgrade I am referring to >> >> >> >>> Or do you mean, when a DoT connection is blocked by e.g. a firewall (or >>> other network enforcement device), that an RST is generated? I believe the >>> RST requires sequence number validation before it can be processed by the >>> TCP stack, which means the entity doing the RST generally needs to be in >>> the data path. Other than "lucky guess" or "high volume attempts", I don't >>> believe RST to be a serious threat. >>> >> >> path manipulation attacks are real. arp attacks.. bootp attacks.. rouge >> access points. stingray. all kinds of things. unauthenticated network >> packets are just that: unauthenticated. RST (or blackhole) is a good >> indication that a path isn't going to work - its not a good indication of >> who is expressing that policy (or whether it is a policy at all). >> >> Anyhow - I'm really not trying to amp up this thread.. I just felt that >> there were a few relevant points to the discussion that had not been >> introduced. >> > > Okay, that's good to know, and I think we are in agreement (i.e. that > inference is a poor substitute for declarations.) > > I think that this is an area that needs thought and mechanism development, > possibly aligned with DoT/DoH operation, possibly not (or orthogonal to > them). > > Brian > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus wrote: > > > On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >>> >>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do >> not believe anyone has proposed explicit downgrade triggers. >> > > that's the downgrade I am referring to > > > >> Or do you mean, when a DoT connection is blocked by e.g. a firewall (or >> other network enforcement device), that an RST is generated? I believe the >> RST requires sequence number validation before it can be processed by the >> TCP stack, which means the entity doing the RST generally needs to be in >> the data path. Other than "lucky guess" or "high volume attempts", I don't >> believe RST to be a serious threat. >> > > path manipulation attacks are real. arp attacks.. bootp attacks.. rouge > access points. stingray. all kinds of things. unauthenticated network > packets are just that: unauthenticated. RST (or blackhole) is a good > indication that a path isn't going to work - its not a good indication of > who is expressing that policy (or whether it is a policy at all). > > Anyhow - I'm really not trying to amp up this thread.. I just felt that > there were a few relevant points to the discussion that had not been > introduced. > Okay, that's good to know, and I think we are in agreement (i.e. that inference is a poor substitute for declarations.) I think that this is an area that needs thought and mechanism development, possibly aligned with DoT/DoH operation, possibly not (or orthogonal to them). Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:58 AM Ray Bellis wrote: > > > On 25/03/2019 09:28, Ian Swett wrote: > > One way DoH may be faster than DoT in the near future is that DoH can go > > over HTTP/3 via QUIC and avoid head of line blocking like Do53. > > Head of line blocking shouldn't happen on a modern Do53 server. > > See RFC 7766 §6.2.1.1 > > I've seen this confusion before, so I can clear it up! Ray is (I believe) referring to the flexible re-ordering of DNS request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less flexibility in granularity iirc). That addresses hol-blocking problems due to the time the server spends building replies. Ian is (I believe) referring to head of line blocking problems related to TCP's in-order delivery semantic and packet loss. TCP packet loss will delay the delivery of received packets if there are outstanding unreceived lower-numbered packets. If the data in these packets are unrelated (e.g. different DNS request/reply pairs) - that causes head of line blocking to the application. That's true of http/2 and RFC7766 (anything tcp based really). QUIC streams provide a mechanism for identifying which sequences actually need to have that dependency. DoH with H3 would use separate streams for separate requests (as different HTTP exchanges are inherently on different streams). Its a shame that the term hol blocking is used for both scenarios - it has caused a lot of confusion. hth -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson wrote: > > >> >> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do > not believe anyone has proposed explicit downgrade triggers. > that's the downgrade I am referring to > Or do you mean, when a DoT connection is blocked by e.g. a firewall (or > other network enforcement device), that an RST is generated? I believe the > RST requires sequence number validation before it can be processed by the > TCP stack, which means the entity doing the RST generally needs to be in > the data path. Other than "lucky guess" or "high volume attempts", I don't > believe RST to be a serious threat. > path manipulation attacks are real. arp attacks.. bootp attacks.. rouge access points. stingray. all kinds of things. unauthenticated network packets are just that: unauthenticated. RST (or blackhole) is a good indication that a path isn't going to work - its not a good indication of who is expressing that policy (or whether it is a policy at all). Anyhow - I'm really not trying to amp up this thread.. I just felt that there were a few relevant points to the discussion that had not been introduced. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25 Mar 2019, at 10:25, Stephen Farrell wrote: > I see a problem with the above argument. DNS means nothing to > most people, so I can't see how they can ever make the informed > decision you mention. I view that as a research question (I don’t accept your assertion, but neither can I disprove it). That is- could a question be formed around local network trust that encompasses this component? Possibly. Eliot ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Hiya, On 25/03/2019 09:13, Eliot Lear wrote: > Putting aside legal language, but Brian’s basic notion is that the > user can make an informed decision and the network can express its > policies, with which the user can agree or not agree (and go > elsewhere). Having the protocol elements to permit this sort of > agreement is its own tussle. I see a problem with the above argument. DNS means nothing to most people, so I can't see how they can ever make the informed decision you mention. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
ts nice to have a thread where bike shedding of terms is actually on topic, and the point of the draft. On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola wrote: > > > I don't know if these terms are already defined somewhere else, but the > distinction that I've found most useful in the DoH discussion is "local > resolver" (i.e. the one provided on/by the local network the user connects > to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go > beyond the Internet access provider's network). Some of the issues happen, > and already happen today, as soon as the user adopts a remote resolver, > even with plain old DNS. > > I agree with you that this is the important logical distinction. My only quibble is that local and remote can have varied (and multiple) scopes - so its a little hard to apply the terms concretely. I'm thinking more along the lines of Access Network Resolver and Network Independent Resolver to capture the same idea. [I originally sent this note by accident to Vittoria without a cc to the list. Sorry Vittorio for the dup!] On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola wrote: > > Il 24 marzo 2019 alle 7.42 Paul Hoffman ha > scritto: > > > > > > Greetings again. As y'all have seen over the past few weeks, the > discussion of where DNS resolution should happen and over what transports > has caused some people to use conflicting terms. As a possible solution to > the terminology problems, I am proposing a few abbreviations that people > can use in these discussions. The draft below, if adopted by the DNSOP WG, > would update RFC 8499 with a small set of abbreviations. > > I don't know if these terms are already defined somewhere else, but the > distinction that I've found most useful in the DoH discussion is "local > resolver" (i.e. the one provided on/by the local network the user connects > to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go > beyond the Internet access provider's network). Some of the issues happen, > and already happen today, as soon as the user adopts a remote resolver, > even with plain old DNS. > > I agree that another set of problems derives instead from applications > using a resolver different than the one configured in the operating system, > which may or may not be the local resolver. So it's fine to define a couple > of terms like "DaT" and "DaO", though I don't really like these two > acronyms :-) In my draft I introduce the terms "network-level name > resolution", "application-level name resolution" and "application-level > resolver selection". They are not acronyms, but I think they would be more > understandable in a discussion than more and more acronyms. > > (I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is > just clearer.) > > Ciao, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Hi, > On 24 Mar 2019, at 23:25, Paul Wouters wrote: > >> The blocking of DoT to a given provider should be interpreted as an explicit >> policy. Users should be informed >> that they may, and very likely will, be violating someone’s policy, if they >> choose to use DoH in that >> circumstance, and that they may be violating laws by doing so, and should >> only do so if they are willing to >> accept that risk. > > Again, this is the network operator centric view. There are many hostile > networks that would block DoT just so that they could monetize (legally > or illegally!) from my harvested DNS data. I can assure you the warning > you want to write to users would be very different from the warning I > would want to give those users. Which is why the IETF doesn't do > banners towards endusers. Putting aside legal language, but Brian’s basic notion is that the user can make an informed decision and the network can express its policies, with which the user can agree or not agree (and go elsewhere). Having the protocol elements to permit this sort of agreement is its own tussle. Eliot___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu
wrote:
> On Mon, 25 Mar 2019 at 09:15, Brian Dickson
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
>> wrote:
>>
>>> I'm not pushing against DoT per se in this thread, I am pushing against
>>> the notion that a client has an obligation to the network to provide a
>>> clear channel for traffic analysis and downgrade triggers.
>>>
>>> fwiw - there are lots of reasons an http client is going to be
>>> interested in an http substrate beyond just traffic analysis defense. It
>>> has the potential for better overall application responsiveness - by
>>> sharing connections and handshakes with other http data. I don't think that
>>> particular discussion is important to this thread.
>>>
>>
>>
>> The DoH operators who have made public statements (google and cloudflare
>> are two I am aware of), have specifically indicated that NO OTHER HTTPS
>> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>>
>> So, the handshakes and sharing argument is specious at best, and bogus at
>> worst.
>>
>
> That may be true for Google and Cloudflare right now. But if I will be
> running my own DoH server it would probably be on AWS or compute engine
> along with any other website I'm currently running, so the connection
> sharing WILL happen.
>
Okay, that's a useful anecdote/datapoint.
Have you considered whether you will need to operate DoT as well, in case
DoH is blocked from some networks that do not also block DoT?
I.e. fallback from DoH to DoT rather than fall all the way back to Do53?
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25/03/2019 09:28, Ian Swett wrote: One way DoH may be faster than DoT in the near future is that DoH can go over HTTP/3 via QUIC and avoid head of line blocking like Do53. Head of line blocking shouldn't happen on a modern Do53 server. See RFC 7766 §6.2.1.1 Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: New draft for consideration:
Bonjour uses DNS or mDNS. If it’s using DNS, it can in principle use DoT or DoH, and indeed “Back to my Mac” was using DoT before it was specified in an RFC. That functionality is still in the open source mDNSResponder code. I realize that this is somewhat tangential to the point you were making but wanted to clarify this detail. On Sun, Mar 24, 2019 at 22:26 Matthew Pounsett wrote: > > > On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli wrote: > >> >> >> On Mar 24, 2019, at 08:59, Matthew Pounsett wrote: >> >> >> >> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman >> wrote: >> >>> >>> > I'm also not too hot for conflating "user consciously changes >>> > /etc/resolv.conf or equivalent" with "application makes the choice for >>> the >>> > user". >>> >>> The split here is more "someone changes from traditional without the >>> user knowing, when the user cares". If you have a better way to express >>> that, that would be great. >>> >>> > Perhaps we should talk about 'Per-application stubs'? Because this is >>> the >>> > nub. >>> >>> Maybe, but I'm hesitant to make the break that way because some >>> applications' stubs use the traditional resolver, others don't. I would be >>> hesitant to conflate those two. >>> >> >> I don't think the current wording for DaO expresses the same point that >> you've made here. In particular, mentioning that DaO might refer to a user >> modifying /etc/resolv.conf is inconsistent with the intent that DaO is >> sending queries somewhere other than where the traditional configuration >> says. /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the >> traditional place to configure that. Whatever that file says, I think any >> resolver that is consulting that file to find its upstreams is doing DaT.. >> >> >> I think we’re at the point where using acronyms is is obscuring the >> detail of what is being described. If and acronym describes a protocol or >> an architectural feature that is unambiguous, great. >> >> >> How about: >>DaO: DNS resolution between a stub resolver and a recursive resolver >> that >>differs from the recursive resolver configured in the traditional >>location(s) for a system. >> >> >> This describes a multitude of systems of varying implementation. It would >> seem for example to include bonjour, a tor client, some vpns and many >> operating system container environments. >> > > I may be wrong, but I don't believe bonjour uses RDoT or DoH. > > The VPNs you reference are, I think, intended to be covered by the term, > so I think the definition works there. > > I don't think I have an opinion on whether Tor should or shouldn't be > covered by the definition (although others might), so if you wanted to > suggest text that excluded it I think people would consider that. > > I don't think container environments are included in the definition > either, because in a container environment the container's resolution path > is the traditional point of configuration for that type of system. Perhaps > the word "traditional" is too ambiguous, and leads people to think more > "historical" than "typical"? > > >> >> DaO can be configured by a user changing where a >>stub resolver gets its list of recursive servers, or an application >> running >>RDoT or DoH to a resolver that is not the same as the resolver >> configured >>in the traditional location for the operating system. >> >> ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, 25 Mar 2019 at 09:15, Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic analysis and downgrade triggers.
>>
>> fwiw - there are lots of reasons an http client is going to be interested
>> in an http substrate beyond just traffic analysis defense. It has the
>> potential for better overall application responsiveness - by sharing
>> connections and handshakes with other http data. I don't think that
>> particular discussion is important to this thread.
>>
>
> Actually, it really is.
>
> At a minimum it needs to be treated as an assertion that is subject to
> validation or refutation.
>
> This is a refutation:
>
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>
> So, the handshakes and sharing argument is specious at best, and bogus at
> worst.
>
That may be true for Google and Cloudflare right now. But if I will be
running my own DoH server it would probably be on AWS or compute engine
along with any other website I'm currently running, so the connection
sharing WILL happen.
> The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
> DoT does not require the encoding/decoding of the DNS messages (plus all
> the other HTTP overhead).
> Both DoT and DoH require DNS messages in wire format be constructed first,
> and after whatever decoding, wire format responses processed by the client.
>
> A cursory analysis of the logic -- extra encoding vs no extra encoding --
> essentially proves by "the triangle inequality"* that DoH cannot be faster
> than DoT when comparing same-client to same-server.
>
> Brian
>
> *(the sum of lengths of two sides is greater or equal to the length of the
> third side) In this case two sides are the same length (processing of TLS
> and DNS) and the other side is extra processing of HTTP encoding, headers,
> etc., and the sum is (HTTP + common path) , compared with (common path).
> HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
>
>
>>
>> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>>> wrote:
>>>
>>>
>>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
This is important for network operators in identifying encrypted DNS
traffic,
>>>
>>> not all clients acknowledge a network's right to do such things at all
>>> times. And of course it would be useful to tell the difference between
>>> policy and a RST injection attack.
>>>
>>> If the client does acknowledge the network has the right to set policy -
>>> then the policy can be set on the client using existing configuration
>>> mechanisms that allow the client to differentiate between authorized
>>> configuration and perhaps less-authorized folks identifying their DNS
>>> traffic. This is well worn ground in the HTTP space.
>>>
>>>
>>> What I find interesting, is that as far as I can tell, everything you
>>> wrote applies equally to DoH and DoT, if the transport is the only
>>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>>> DoT.
>>>
>>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>>
>>> Brian
>>>
>> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
I have seen such a public statement from Google. Where have you seen a
similar statement from Mozilla/Cloudflare?
I asked for such a statement from Mozilla recently (on this mailing
list). No answer yet.
Steinar Haug, AS2116
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
> Il 24 marzo 2019 alle 7.42 Paul Hoffman ha scritto: > > > Greetings again. As y'all have seen over the past few weeks, the discussion > of where DNS resolution should happen and over what transports has caused > some people to use conflicting terms. As a possible solution to the > terminology problems, I am proposing a few abbreviations that people can use > in these discussions. The draft below, if adopted by the DNSOP WG, would > update RFC 8499 with a small set of abbreviations. I don't know if these terms are already defined somewhere else, but the distinction that I've found most useful in the DoH discussion is "local resolver" (i.e. the one provided on/by the local network the user connects to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go beyond the Internet access provider's network). Some of the issues happen, and already happen today, as soon as the user adopts a remote resolver, even with plain old DNS. I agree that another set of problems derives instead from applications using a resolver different than the one configured in the operating system, which may or may not be the local resolver. So it's fine to define a couple of terms like "DaT" and "DaO", though I don't really like these two acronyms :-) In my draft I introduce the terms "network-level name resolution", "application-level name resolution" and "application-level resolver selection". They are not acronyms, but I think they would be more understandable in a discussion than more and more acronyms. (I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is just clearer.) Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
I think it would be better to not combine (and conflate) two or more issues
(which may not be directly related).
Plus, this is approaching a "straw man" argument: the notion of
"obligation".
I might not have been clear enough previously. I am arguing against
obligating client applications to take actions that users have not
explicitly given permission to do.
In this case, the action is: "Use Do{HT} service X".
If X is not on the user's list of Do{HT} providers the user has
selected/configured, then my position is the user MUST be prompted prior to
using X, or absent a user interaction mechanism (UI), then X MUST NOT be
used. This includes the case where X is Do53 (regular DNS), if the user has
selected/configured that Do{HT} is required.
In other words, I am proposing that clients not be built so as to be
susceptible to downgrade attacks (whether by the network operator, or by an
attacker). This is directly analogous to attacks on TLS itself for
downgrading TLS versions or cipher selections. In fact, IMHO, Do{TH} should
take a page from the whole TLS state machine, where the client selects
among the servers' offered parameters, possibly deciding to not complete
the handshake if any of a host of issues are discovered (cert validation,
among others).
>
> One of the notions presented here is that unauthenticated RST injection
> forgery is an acceptable, perhaps in the minds of some even desirable,
> signal for DoT to trigger downgrades and, further, that clients are
> obligated to create a clear signal to the network to enable this approach.
>
This is a separate issue.
Other than blocking all-but-a-few (or all, or a few) DoT servers, I do not
believe anyone has proposed explicit downgrade triggers. Or do you mean,
when a DoT connection is blocked by e.g. a firewall (or other network
enforcement device), that an RST is generated? I believe the RST requires
sequence number validation before it can be processed by the TCP stack,
which means the entity doing the RST generally needs to be in the data
path. Other than "lucky guess" or "high volume attempts", I don't believe
RST to be a serious threat.
> One issue is that you cannot differentiate this signal between a party you
> may want to cooperate with (e.g. your enterprise controller) and an
> attacker - that's the nature of an unauthenticated injection. But there are
> authenticated enterprise configuration methods available for expressing
> policy directly to the client in a trusted way. Indeed my post centered
> around the notion of https interception being a necessary outcome of DoH in
> the enterprise - my point is basically if you can do https interception
> then you are doing enterprise config - consider a config to still do
> secured DNS with a server that implements the enterprise policy rather than
> doing interception.
>
I agree that there is a need for both service discovery (local and
pre-selected Do{TH} providers), and service *policy* discovery, ideally
authenticated and secured (subject to provider implementations adhering to
mechanisms to provide secure authenticity proofs).
>
> And if you do that an enterprise client can, by using its own do{th}
> server, also enjoy the benefits of transport security and be confident that
> the policy server it intends to use is actually the one in use.
>
I agree with this.
I believe there is widespread interest in solving this problem.
However, I believe there is a need for the solution to this problem being
coordinated between the DoH and DoT groups, seeing as the DNS operators
have a significant interest in both DoT and DoH being served on their
servers, and thus a strong interest in any relevant components (discovery,
validation, etc.) being uniformly specified across both protocols.
It might be worth having an AD/WG discussion on where these should be
developed; it might be better to do in DNSOP, rather than DPRIVE or DOH, or
alternatively spinning up a new, very focused WG for this work (I would not
be in favor of the latter).
Brian
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>> This is important for network operators in identifying encrypted DNS
>>> traffic,
>>>
>>
>> not all clients acknowledge a network's right to do such things at all
>> times. And of course it would be useful to tell the difference between
>> policy and a RST injection attack.
>>
>> If the client does acknowledge the network has the right to set policy -
>> then the policy can be set on the client using
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic analysis and downgrade triggers.
>>
>> fwiw - there are lots of reasons an http client is going to be interested
>> in an http substrate beyond just traffic analysis defense. It has the
>> potential for better overall application responsiveness - by sharing
>> connections and handshakes with other http data. I don't think that
>> particular discussion is important to this thread.
>>
>
> Actually, it really is.
>
> At a minimum it needs to be treated as an assertion that is subject to
> validation or refutation.
>
> This is a refutation:
>
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>
> So, the handshakes and sharing argument is specious at best, and bogus at
> worst.
>
> The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
> DoT does not require the encoding/decoding of the DNS messages (plus all
> the other HTTP overhead).
> Both DoT and DoH require DNS messages in wire format be constructed first,
> and after whatever decoding, wire format responses processed by the client.
>
> A cursory analysis of the logic -- extra encoding vs no extra encoding --
> essentially proves by "the triangle inequality"* that DoH cannot be faster
> than DoT when comparing same-client to same-server.
>
> Brian
>
> *(the sum of lengths of two sides is greater or equal to the length of the
> third side) In this case two sides are the same length (processing of TLS
> and DNS) and the other side is extra processing of HTTP encoding, headers,
> etc., and the sum is (HTTP + common path) , compared with (common path).
> HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
>
>
>>
>> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>>> wrote:
>>>
>>>
>>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
This is important for network operators in identifying encrypted DNS
traffic,
>>>
>>> not all clients acknowledge a network's right to do such things at all
>>> times. And of course it would be useful to tell the difference between
>>> policy and a RST injection attack.
>>>
>>> If the client does acknowledge the network has the right to set policy -
>>> then the policy can be set on the client using existing configuration
>>> mechanisms that allow the client to differentiate between authorized
>>> configuration and perhaps less-authorized folks identifying their DNS
>>> traffic. This is well worn ground in the HTTP space.
>>>
>>>
>>> What I find interesting, is that as far as I can tell, everything you
>>> wrote applies equally to DoH and DoT, if the transport is the only
>>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>>> DoT.
>>>
>>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>>
>>> Brian
>>>
>> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
> fwiw - there are lots of reasons an http client is going to be interested
> in an http substrate beyond just traffic analysis defense. It has the
> potential for better overall application responsiveness - by sharing
> connections and handshakes with other http data. I don't think that
> particular discussion is important to this thread.
>
Actually, it really is.
At a minimum it needs to be treated as an assertion that is subject to
validation or refutation.
This is a refutation:
The DoH operators who have made public statements (google and cloudflare
are two I am aware of), have specifically indicated that NO OTHER HTTPS
TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
So, the handshakes and sharing argument is specious at best, and bogus at
worst.
The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
DoT does not require the encoding/decoding of the DNS messages (plus all
the other HTTP overhead).
Both DoT and DoH require DNS messages in wire format be constructed first,
and after whatever decoding, wire format responses processed by the client.
A cursory analysis of the logic -- extra encoding vs no extra encoding --
essentially proves by "the triangle inequality"* that DoH cannot be faster
than DoT when comparing same-client to same-server.
Brian
*(the sum of lengths of two sides is greater or equal to the length of the
third side) In this case two sides are the same length (processing of TLS
and DNS) and the other side is extra processing of HTTP encoding, headers,
etc., and the sum is (HTTP + common path) , compared with (common path).
HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>> This is important for network operators in identifying encrypted DNS
>>> traffic,
>>>
>>
>> not all clients acknowledge a network's right to do such things at all
>> times. And of course it would be useful to tell the difference between
>> policy and a RST injection attack.
>>
>> If the client does acknowledge the network has the right to set policy -
>> then the policy can be set on the client using existing configuration
>> mechanisms that allow the client to differentiate between authorized
>> configuration and perhaps less-authorized folks identifying their DNS
>> traffic. This is well worn ground in the HTTP space.
>>
>>
>> What I find interesting, is that as far as I can tell, everything you
>> wrote applies equally to DoH and DoT, if the transport is the only
>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>> DoT.
>>
>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>
>> Brian
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.
And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.
fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.
On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson
wrote:
>
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>> traffic,
>>
>
> not all clients acknowledge a network's right to do such things at all
> times. And of course it would be useful to tell the difference between
> policy and a RST injection attack.
>
> If the client does acknowledge the network has the right to set policy -
> then the policy can be set on the client using existing configuration
> mechanisms that allow the client to differentiate between authorized
> configuration and perhaps less-authorized folks identifying their DNS
> traffic. This is well worn ground in the HTTP space.
>
>
> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>
> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> On 25 Mar 2019, at 6:06 pm, Daniel Stenberg wrote: > > On Sun, 24 Mar 2019, Vittorio Bertola wrote: > >> In today's "plain DNS" world, I choose a DNS resolver that provides that >> kind of filters for me, I set it up on my router, and my router pushes it to >> my smart TV via DHCP. What is the "existing configuration mechanism" that >> allows me to set this policy in the DoH world, i.e. if the TV came equipped >> with applications preconfigured to use their own remote resolver via DoH? > > We can easily turn this example the other way around. > > With Do53 in your TV, your kids can easily fool your TV with their own DHCP > responses or by intercepting and intefering with the DNS traffic while you're > at work. > > With DoH used in the TV, set to use a trusted server, they can’t. Which won’t work if the network is filtering Do53 traffic to non approved servers or if the TV is manually configured with Do53 or DoT servers and the TV’s configuration is locked down. Yes, TV’s do have the ability to lock this part of the configuration down same as filters on program ratings can be enforced provided the data stream includes the rating information. The problem with DoH is that it makes filtering difficult. That is both a good and a bad thing depending on your perspective and responsibilities. It’s a pandora’s box. > -- > > / daniel.haxx.se > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, 24 Mar 2019, Vittorio Bertola wrote: In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH? We can easily turn this example the other way around. With Do53 in your TV, your kids can easily fool your TV with their own DHCP responses or by intercepting and intefering with the DNS traffic while you're at work. With DoH used in the TV, set to use a trusted server, they can't. -- / daniel.haxx.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
