Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček wrote: > On 21.8.2018 04:38, Tom Pusateri wrote: >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (down) the chain, the

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 21.8.2018 04:38, Tom Pusateri wrote: > Come to think of it, DNSSEC validation in the stub resolver or browser > is really a place DoH could shine. Instead of all the round trips > required for validating up (down) the chain, the webserver could package > up all those validated records and push

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Tom Pusateri wrote: > Come to think of it, DNSSEC validation in the stub resolver or browser > is really a place DoH could shine. Instead of all the round trips > required for validating up (down) the chain, With DNS to a recursive server (UDP, TCP, or TLS) as currently deployed, you only need

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> Il 20 agosto 2018 alle 18.51 Ted Lemon ha scritto: > > > > So I cannot immediately recall cases in which a network operator in Europe > > is filtering out things that a user wants and can lawfully access. But you > > mention that your network operator is spoofing the DNS and stifling

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Tony Finch wrote: > > A URI template usually implies the need for DNS queries to resolve the > server name (unless it's an address literal). Would it be plausible to > allow the client to assume that the DoH server IP addresses are the same > as the DNS server addresses, so it can skip the

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton wrote: > You, like Ted, are looking at the problem the wrong way 'round. And this, in a nutshell, is why this discussion has gone on so long. If you just caricature what the people you're conversing with say, then it's inevitably going to go like

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> Il 20 agosto 2018 alle 20.11 Paul Vixie ha scritto: > the DOH people should be told not to proceed to draft > standard until their design accommodates the needs of network operators. This is, honestly, what I'd have expected the "IETF leadership" (IESG, IAB...) to say: this new protocol

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> Il 21 agosto 2018 alle 5.47 John Levine ha scritto: > * - When I talk to security people at mail providers, they have > endless tales of people who take the mail out of their spam folder and > click on the links, you know, just in case it was filtered wrong. If > you know it's bad stuff, you

Re: [DNSOP] Global DNS architecture changes, "the camel", and so on

On 08/20/2018 07:22 PM, Andrew Sullivan wrote: > • Does TCP need to become the norm (particularly for the above use > case)? TCP support is mandatory now, if that's what you mean (or wasn't clear). https://tools.ietf.org/html/rfc7766#section-5 In particular, for forwarding it actually

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> Il 21 agosto 2018 alle 16.47 Philip Homburg ha > scritto: > > > > If I got it well, what you are trying to bypass is your ISP's > > security filter that prevents you from connecting to malware or to > > illegal content (e.g. intellectual property violations and the > > likes). > > As a

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 04:47 PM, Philip Homburg wrote: >> If I got it well, what you are trying to bypass is your ISP's >> security filter that prevents you from connecting to malware or to >> illegal content (e.g. intellectual property violations and the >> likes). > As a user, I think there is little

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 3:30 AM, Marek Vavruša > wrote: > > On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček > wrote: >> On 21.8.2018 04:38, Tom Pusateri wrote: >>> Come to think of it, DNSSEC validation in the stub resolver or browser >>> is really a place DoH could

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 7:33 AM, Tony Finch wrote: > > Tom Pusateri wrote: > >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (down) the chain, > > With DNS to a

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

Howdy, I note that section 4.4 calls out TCP transport and says this: 4.4. Behaviour with TCP Transport A DNS responder MAY behave differently when processing ANY queries received over different transport, e.g. by providing a conventional ANY response over TCP whilst using one of the

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

Ted, Would it be acceptable to just do s/TCP/Connection oriented Transport/ Olafur On Tue, Aug 21, 2018 at 12:48 PM, Ted Hardie wrote: > Howdy, > > I note that section 4.4 calls out TCP transport and says this: > > 4.4. Behaviour with TCP Transport > >A DNS responder MAY behave

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

We aren’t even talking about the same thing. I’m talking about figuring out whether we need to offer guidance for how a host implementation would handle conflicting information and, if so, what guidance to offer. You are talking about one of a number of different ways of configuring DoT. On Tue,

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

What conflicting information? On 08/21/2018 08:11 PM, Ted Lemon wrote: We aren’t even talking about the same thing. I’m talking about figuring out whether we need to offer guidance for how a host implementation would handle conflicting information and, if so, what guidance to offer.  You are

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 05:48 AM, Ted Lemon wrote: On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton > wrote: You, like Ted, are looking at the problem the wrong way 'round. And this, in a nutshell, is why this discussion has gone on so long.  If you just caricature what

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 09:19 AM, Vladimír Čunát wrote: Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel:-D This perspective that users "trust" their network

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 09:25 AM, Ted Lemon wrote: DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed.   It isn't "simple" simply because it addresses only one specific use case. If your "conflicting information"

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

This is one of the problems with security. It always comes with tradeoffs, and it always looks different depending on your perspective. In fact, though, the people who are currently providing DoH service actually have much greater visibility into the malware problem than you possibly can.

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Vittorio, On Aug 21, 2018, at 3:33 AM, Vittorio Bertola wrote: > If so, I can accept your use case: a smart user, knowing what he is doing, > does not want anyone else to sanitize his queries for him. But I don't see > why the best solution to your use case - which is quite a minority case,

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Tue, Aug 21, 2018 at 1:37 PM David Conrad wrote: > Vittorio, > > On Aug 21, 2018, at 3:33 AM, Vittorio Bertola < > vittorio.bert...@open-xchange.com> wrote: > > If so, I can accept your use case: a smart user, knowing what he is doing, > does not want anyone else to sanitize his queries for

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

On Tue, Aug 21, 2018 at 2:01 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : DNS Scoped Data Through "Underscore" Naming of > Attribute

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

>In fact, roaming wi-fi >connections, while still relevant (especially for international tourists), are > getting less and less used, since everyone now gets several gigabytes of EU-w >ide mobile data per month included with their base mobile fee. I assume that you are aware that with HD video,

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use Author : Dave

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

In article <153487442185.9578.1065167157914269...@ietfa.amsl.com> you write: >Title : DNS Scoped Data Through "Underscore" Naming of > Attribute Leaves >Author : Dave Crocker > Filename: draft-ietf-dnsop-attrleaf-13.txt It looks fine except that

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

On 8/21/2018 11:10 AM, Bob Harold wrote: Minor typo: "Specifiction" -> "Specification" that might have been a freudian slip. that, and the spelling corrector must not have looked into xml attributes. sigh. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Tom Pusateri wrote: it should follow therefore that i do NOT want to use UDP/53 + Cookies unless there is no alternative. DoT will be preferred. (DTLS or SCTP would be even better, but i'm only picking from items now-on-menu.) Since you can already do DoT today without an additional

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 21 Aug 2018, at 16:23, Vittorio Bertola wrote: > > And I have yet to see a statement from the DoH community that Mozilla's idea > of making DoH the default and disregarding whatever resolver is being > configured in the system via DHCP is not a good one. Why would/should the DoH community

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Scoped Data Through "Underscore" Naming of Attribute Leaves Author : Dave Crocker

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

On Tue, Aug 21, 2018 at 2:02 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : DNS Attrleaf Changes: Fixing Specifications with >

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

In your letter dated Tue, 21 Aug 2018 18:19:39 +0200 you wrote: >Ehm, we somehow forgot that this thread is supposed to be about DHCP, so >that's only the "uninteresting" case where you do trust the ISP and want >to use their DNS over a secure channel :-D There are still plenty of use cases. An

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Philip Homburg wrote: If I got it well, what you are trying to bypass is your ISP's security filter that prevents you from connecting to malware or to illegal content (e.g. intellectual property violations and the likes). As a user, I think there is little reason to trust an ISP. ...

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

On 8/21/2018 11:15 AM, John Levine wrote: It looks fine except that section 6.1 on wildcards vs. underscores is gone. Was that deliberate? I don't recall anyone complainging about it. Moved to Section 1.4. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Tom Pusateri wrote: The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. But the web/DoH server has more knowledge that the stub doesn’t have yet and so it can benefit from this knowledge in a way that the stub resolver can’t. for this to matter, the user will

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 2:54 PM, Paul Vixie wrote: > > > > David Conrad wrote: >> Vittorio, >> >> ... >> >> Perhaps I’m misunderstanding: are you saying the folks who provide >> resolution services in a DoH world would have incentive to not follow >> basic security measures? > > noting that

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

this, joyfully, is a very good question. Tom Pusateri wrote: Ok, so as Vladimír said, getting back to DHCP… 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present and using the existing DHCP DNS options 3. You

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 3:30 PM, Paul Vixie wrote: > > this, joyfully, is a very good question. > > Tom Pusateri wrote: > >> Ok, so as Vladimír said, getting back to DHCP… >> >> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re >> comfortable with DNS over UDP/53 as long as

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-13.txt

Folks, Just posted the revised base and fix attrleaf documents. I tried to fold in all of the suggested changes. I've checked both documents but would appreciate a separate audit, to make sure... d/ A new version of I-D, draft-ietf-dnsop-attrleaf-13.txt has been successfully submitted

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

David Conrad wrote: Vittorio, ... Perhaps I’m misunderstanding: are you saying the folks who provide resolution services in a DoH world would have incentive to not follow basic security measures? noting that i am not vittorio, i will punch in as follows. i do not expect CF to block

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

>Then you have a problem that's not solvable in DNS itself (yet).  That's >what people usually forget to consider. > >The hostnames are clear-text in https hanshakes (so far), and it seems >relatively easy to collect those.  So, by tunneling *only* DNS you don't >make it much more difficult for

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel :-D On 08/21/2018 05:34 PM, Philip Homburg wrote: >> Then you have a problem that's not solvable in DNS itself

[DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Tue, Aug 21, 2018 at 11:23 AM, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > Still, I'm all in favour of encrypting and authenticating DNS connections > when you are in that situation. However, this should not be done in a way > that breaks many other use cases. > How do we

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed. It isn't "simple" simply because it addresses only one specific use case. On Tue, Aug 21, 2018 at 12:19 PM, Vladimír Čunát wrote: > Ehm, we somehow forgot

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> If I got it well, what you are trying to bypass is your ISP's > security filter that prevents you from connecting to malware or to > illegal content (e.g. intellectual property violations and the > likes). As a user, I think there is little reason to trust an ISP. If you take a mobile device,

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote: Ted, Would it be acceptable to just do  s/TCP/Connection oriented Transport/  For RFC 7901 we used "source-IP-verified transport" Paul ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

On Tue, Aug 21, 2018 at 10:03 AM, Paul Wouters wrote: > On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote: > > Ted, Would it be acceptable to just do >> s/TCP/Connection oriented Transport/ >> > > For RFC 7901 we used "source-IP-verified transport" > > If this is the only characteristic that the