Re: [dns-privacy] Authoritative DoT or DoH
> On Mar 14, 2019, at 12:18 PM, Henderson, Karl > wrote: > Is there any compelling reason at this point to be considering DoH for > recursive resolver-to-authoritative name server communications? Nope, because there’s already a DoT for recursive-to-authoritative draft. https://www.ietf.org/archive/id/draft-bortzmeyer-dprive-resolver-to-auth-01.txt -Bill signature.asc Description: Message signed with OpenPGP ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Authoritative DoT or DoH
In the last couple of days there has been a lot of activity concerning DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN and IETF drafts: draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients. These discussions have focused on DoH for client (typically web browser) communication with recursive resolvers, and its comparisons with DoT for this purpose. Is there any compelling reason at this point to be considering DoH for recursive resolver-to-authoritative name server communications? As I noted at the DPRIVE interim meeting, the working group needs empirical studies looking at performance and attack vectors for authoritative DNS encryption. Unless there are compelling reasons to consider Authoritative DoH, I propose the working group focus its authoritative DNS encryption assessments around Authoritative DoT. In support, I am willing to co-author an Authoritative DoT operational consideration draft in order to outline the operational challenges the community needs to address - similar to the draft-reid-doh-operator draft between client and recursive. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [hrpc] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
Paul, I'm trying to understand your scenario. If you ran your own DoH server in your network (doing RDNS or whatnot), and the DoH server is distributed to clients via DHCP + a protocol upgrade mechanism, would that address the concerns you are listing? Vinicius Fortuna On Thu, Mar 14, 2019 at 1:33 AM Paul Vixie wrote: > On Thursday, 14 March 2019 00:48:53 UTC Ted Lemon wrote: > > On Mar 12, 2019, at 2:52 PM, Paul Vixie wrote: > > > please do not relegate discussions about the loss of operator control > over > > > the RDNS control plane > > > > Although it’s certainly true that DNS is used as a control plane by many > > operators, there is no standard “RDNS control plane.” ... > > i don't think lack of standardization is the same as not existing. devices > which honour the dhcp-assigned rdns service, work as expected, and as > intended. devices who ignore that setting and seek their own rdns by their > own > internal configuration, will often not work at all. > > because many of us amend our locally visible dns namespace with things > like > .corp or .home or .local, it's even more vital that devices respect the > rdns > assignment i make. the dns content i want to be visible on my network, > have to > be visible on my network. > > because many of us won't allow pirate or malware or otherwise undesired > DNS > lookups to succeed, either because we don't like the name, or we don't > like > the result of the query, or we don't like some name server that would be > involved in resolving it. the dns content i don't want to be visible on my > network, have to not be visible on my network. > > from the days before dhcp when we typed these numbers in by hand, until > now, > it has always been the expectation that rdns was part-and-parcel of local > network service. no different in that regard from dhcp or arp, neither of > which is standardized under the heading, "control plane", yet, are. > > so i think i'm not going to follow you down this terminological rabbit > hole. > the reason that internet creations of yours will work better on my network > if > you treat the rdns as part of my control plane is, because it's my network > and > that's how i operate it. you're not welcome to bypass it, nor answer dhcp > requests when you're not my dhcp server, nor answer arp requests when you > aren't the device i assigned that address to. > > you can call that tautological if you wish. but it's the life my networks > lead. external DoH providers are explicitly not welcome to provide service > to > malware or intruders who get into my network -- because rdns is part of my > control plane, and like arp and dhcp, i control it and i monitor it, for > $reasons. > > > The problem with the discussion we’ve been having about DoH and how it > > affects your “RDNS control plane” is that we’re talking past each other, > > not that the discussion should be had elsewhere. It’s fine for there to > > be a discussion, but if there is going to be a discussion, participants > > need to engage constructively, and not just fling slogans at each other.. > > i think i've flung considerably more than slogans, and, it's been > exhausting. > > vixie > > > ___ > hrpc mailing list > h...@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
On Mar 14, 2019, at 10:41 AM, Ralf Weber wrote: > Well as you said it is something that will not get consensus at the IETF, so > why work on that? However as you said these RDNS control planes exist in real > life and even if there is no IETF standard for it, the IETF should consider > actual deployments when doing work and not just IETF standards IMHO and that > is what the drafts out there trying to do, bring the view of people operating > these services into the IETF. Sorry, I expressed myself fairly poorly. What I mean is that it’s important to agree on what we are talking about before we try to talk about it, because otherwise a lot of useless back-and-forth happens where one person is arguing from one set of assumptions, and another person is arguing from a different set of assumptions, and neither is able to feel heard. It can feel very political to go meta on a discussion like this, but I think it’s important for people to actually agree on what the various views are of the problem and solution spaces. That is, not agree that this problem is the correct view of the problem, or that that solution is the correct solution to a problem, but to enumerate all the views of the problem that various participants have, and enumerate all the solutions to these various problems that people are interested in. With that overview, a winnowing process is possible; without it, we just have endless non-terminal discussion. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt
On Mon, Mar 11, 2019 at 12:21 PM manu tman wrote: > Hi all, > > I have captured in a draft the mechanism I used during IETF 103 hackathon > and which is available aan experimental module in knot-resolver[0]. I was > taken short with time before cit-off date, but I hope this will better > explain how it works. > > Manu > > [0] > https://gitlab.labs.nic.cz/knot/knot-resolver/tree/master/modules/experimental_dot_auth > > ——— > > > > A new version of I-D, draft-bretelle-dprive-dot-spki-in-ns-name-00.txt > > has been successfully submitted by Emmanuel Bretelle and posted to the > > IETF repository. > > > > Name: draft-bretelle-dprive-dot-spki-in-ns-name > > Revision: 00 > > Title: Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name > Server name > > Document date: 2019-03-11 > > Group: Individual Submission > > Pages: 7 > > URL: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=9TmF-DXxE_0nJ6WyhRNoNSiya3N7h_pVwyRn4qIfD7U= > > Status: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=5eZd00_oyy5t1SFYXYCMfv1fSl22SudK5I3pkCozKFs= > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname-2D00=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=ZTRurE9sjAPDCKcx8dBXgYPs0dE9LmmJ194vl04cn3Q= > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dspki-2Din-2Dns-2Dname=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=jSTn0YgV5vZZxmSgDChO302kZVyakva0HQhlXmV_Ks0=H0At0r1sQEdFc1snO7kIVALaFf-F1zRRHGPf3aUqkk4= > > > > > > Abstract: > > This document describes a mechanism to exchange the Subject Public > > Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated > > with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding > > it as part of its name. The fingerprint can thereafter be used to > > validate the certificate received from the DoT server as well as > > being able to discover support for DoT on the server. > > 6. IANA Considerations " TODO: This document requires IANA actions (new RR type)." What new RR type is needed? Looks to me like all standard RR's. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [hrpc] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
Moin! On 14 Mar 2019, at 10:53, Stephen Farrell wrote: On 14/03/2019 14:41, Ralf Weber wrote: the DoH protocol caused some application providers to experiment with switching resolution per default away from OS and the local network provider I wasn't aware that some application provider was doing this as their default (assuming that's what "per default" means). Can you provide details? The experiment Mozilla did switched these 25000 users to use DoH and gave that option as the default option: https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/ I am aware of what FF/CF have done but I don't believe that was on by default. It was only for nightly users and only for users that have opted in for experiments, but it still IMHO gave a bad impression, as it was viewed by many as a plan send all future DNS traffic to Cloudflare. I still think giving a singular known option as it is the case currently if you click the Dns over HTTPs button in Firefox is a bad idea, but at least it is off per default. So long -Ralf —-- Ralf Weber ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [hrpc] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
Hiya, On 14/03/2019 14:41, Ralf Weber wrote: > the DoH protocol caused some application providers to experiment with > switching resolution per default away from OS and the local network provider I wasn't aware that some application provider was doing this as their default (assuming that's what "per default" means). Can you provide details? I am aware of what FF/CF have done but I don't believe that was on by default. Thanks, S. PS: Apologies if there's a reference in one of the I-Ds, but I don't recall there being one for that assertion. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
Moin! On 13 Mar 2019, at 20:48, Ted Lemon wrote: On Mar 12, 2019, at 2:52 PM, Paul Vixie wrote: please do not relegate discussions about the loss of operator control over the RDNS control plane Although it’s certainly true that DNS is used as a control plane by many operators, there is no standard “RDNS control plane.” If you think there should be, that’s something that the IETF could conceivably work on, but it’s not something that the DoH working group is obligated to treat as a standard use of DNS. And I don’t think it’s a topic on which there is consensus in the IETF. Well as you said it is something that will not get consensus at the IETF, so why work on that? However as you said these RDNS control planes exist in real life and even if there is no IETF standard for it, the IETF should consider actual deployments when doing work and not just IETF standards IMHO and that is what the drafts out there trying to do, bring the view of people operating these services into the IETF. The problem with the discussion we’ve been having about DoH and how it affects your “RDNS control plane” is that we’re talking past each other, not that the discussion should be had elsewhere. It’s fine for there to be a discussion, but if there is going to be a discussion, participants need to engage constructively, and not just fling slogans at each other. So you are ok with having this discussion in DoH, which is good, as the DoH protocol caused some application providers to experiment with switching resolution per default away from OS and the local network provider. A lot of the exhausting thread however was about moving the discussion away from DoH. I’ll personally have the discussion anywhere, but given that the drafts have been given time in doh and people might have planned there schedule around that it should be the place. I also think Paul and others have engaged constructive in the discussion about the topic. So long -Ralf —-- Ralf Weber ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] IETF 104 Agenda for DPRIVE
https://datatracker.ietf.org/doc/agenda-104-dprive/ signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
