Subject: [Add] Mozilla's DoH resolver policy

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Apr 2019 15:20:13 +0000

Of likely interest to this group:
   https://wiki.mozilla.org/Security/DOH-resolver-policy

---

From: nusenu <[email-masked]>
Date: Wed, 10 Apr 2019 17:19:00 +0000

>    https://wiki.mozilla.org/Security/DOH-resolver-policy

I'm surprised they don't include DNSSEC in their requirements
for DoH server operators aiming to join their TRR program

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Apr 2019 13:27:30 -0400 (EDT)

> for DoH server operators aiming to join their TRR program

Same here, although one can argue DNSSEC is just core standard DNS so
they do not need to mention it. Where as query minimalization is still
fairly new.

But especially because some people think DoH/DoT _replaces_ DNSSEC as
security method, it would be good for mozilla to clarify this. Of
course, that also opens them up to answering why they don't actively
support things possible with DNSSEC, such as TLSA support :P

Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 10 Apr 2019 23:12:06 -0400

> they do not need to mention it. Where as query minimalization is still

We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity.  As a browser, we can't condition our behaviour on whether DNSSEC was present and valid for a variety of reasons (some of which we might discuss separately), but we do value resolvers that perform DNSSEC validation.  Requiring query minimization is in keeping with the privacy goal, whereas DNSSEC requirements would expand the scope more than we were comfortable with.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 11 Apr 2019 10:59:35 +0200

Moin!

On 11 Apr 2019, at 5:12, Martin Thomson wrote:
> We don't believe that DNSSEC is essential to our primary goals, which 
> are improving privacy of browsing activity.  As a browser, we can't 
> condition our behaviour on whether DNSSEC was present and valid for a 
> variety of reasons (some of which we might discuss separately), but we 
> do value resolvers that perform DNSSEC validation.
So why not make DNSSEC validation in the resolver a requirement? It 
doesn’t interfere with local policy and offers significant benefits 
for the user. Validation in the client would be nicer, but requiring it 
in the resolver is a good first step.

So long
-Ralf
—--
Ralf Weber

---

From: Valentin Gosu <[email-masked]>
Date: Thu, 11 Apr 2019 11:04:31 +0200

> in the resolver is a good first step.

Because at the moment a DNSSEC failure response from the DoH server is
identical to an NXDOMAIN response, which causes us to fallback to regular
DNS anyway.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1525854

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 11 Apr 2019 11:08:36 +0200 (CEST)

> Il 11 aprile 2019 alle 10.59 Ralf Weber <[email-masked]> ha scritto:
>

More generally, while I understand Mozilla's desire to ensure certain standards to their users, I think it would be better to have a broader definition of what a "good resolver" is, both in terms of scope (not just privacy, but DNSSEC etc), in terms of consensus (and the effort is already ongoing in DPRIVE) and in terms of compliance: I don't know Mozilla's plans for auditing their trusted resolvers (are there any?), but it would make more sense to have an independent industry effort that certifies resolvers, rather than having each of them go through multiple accreditation processes for multiple applications, which would raise entry barriers for public resolvers and, again, promote centralization. 

(Unless we imagine that the choice of resolvers and their accreditation criteria will be a competitive factor among applications, but that would IMHO pose a number of issues.)

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Jim Reid <[email-masked]>
Date: Thu, 11 Apr 2019 10:11:20 +0100

> On 11 Apr 2019, at 10:04, Valentin Gosu <[email-masked]> wrote:
> 
> Because at the moment a DNSSEC failure response from the DoH server is identical to an NXDOMAIN response, which causes us to fallback to regular DNS anyway.

DNSSEC failures return SERVFAIL (something bad/unrecoverable has happened). That's very different from NXDOMAIN responses (the name/class/qtype doesn't exist). I hope DoH servers don't consider these things to be the same because they're not.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 11 Apr 2019 11:15:04 +0200

Moin!

> identical to an NXDOMAIN response, which causes us to fallback to 
No it is not. These are different RCODES.

> See https://bugzilla.mozilla.org/show_bug.cgi?id=1525854
The problem is to decide between SERVFAIL error caused by network events 
or a SERVFAIL by DNSSEC. That is a problem, but if your network or your 
resolvers network is bad why would you fallback to an insecure mechanism 
anyway?

So long
-Ralf
—--
Ralf Weber

---

From: Valentin Gosu <[email-masked]>
Date: Thu, 11 Apr 2019 11:26:28 +0200

> No it is not. These are different RCODES.

Sorry for the confusion, I meant SERVFAIL.

> resolvers network is bad why would you fallback to an insecure mechanism

To prevent disruptions to the user's browsing.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 11 Apr 2019 10:34:24 +0100

On 11/04/2019 10:26, Valentin Gosu wrote:

>      > See https://bugzilla.mozilla.org/show_bug..cgi?id=1525854
>     <https://bugzilla.mozilla.org/show_bug.cgi?id=1525854>

But that's the entire point of DNSSEC!   If the domain fails to 
validate, you *don't go there*

Ray

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 11 Apr 2019 11:37:18 +0200

Moin!

> To prevent disruptions to the user's browsing.
Again why do you think it will get better asking unencrypted? It is a nice
way to find out if someone is using DoH though ;-).

In regular DNS your resolving library had n servers and if one did timeout
or SERVFAIL it did ask the others. It didn’t try a different transport.

Maybe this is a better behaviour for DoH also.

So long
-Ralf
—--
Ralf Weber

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 11 Apr 2019 11:49:41 +0200 (CEST)

> way to find out if someone is using DoH though ;-).

How about not discussing application specific design decisions?

I don't think anyone suggests it is better to ask unencryped, but when the DoH 
server you have configured slowly dies or get DoS'ed or whatever, users will 
appreciate a "way out". In this specific application being discussed, it has a 
soft-fail mode that works like this.

I'm convinced several of us would prefer switching to a different DoH server 
instead, or we even use the hard-fail mode.

The good thing here is that we can all write our own applications to work the 
way we want!

-- 

  / daniel.haxx.se

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Apr 2019 07:36:43 -0400 (EDT)

On Wed, 10 Apr 2019, Martin Thomson wrote:

> We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity.

But I assume it is also not your goal to reduce security for those who
chose mozilla products? You are offering your users a DNS system
override, yet you seem to find it acceptable if that results in a less
secure but more private DNS server being used. That is concerning.

> As a browser, we can't condition our behaviour on whether DNSSEC was present and valid for a variety of reasons (some of which we might discuss separately)

You can but you won't. But I agree there is no need to discuss that
here.

> but we do value resolvers that perform DNSSEC validation.

But you won't value it enough to make it a requirement, even though it
is a core part of the specification of DNS? Again, if you are
reconfiguring a system resource within the application, at the very
least do not reduce security. Requiring DNSSEC validation is a
no-brainer. Those who do not desire such security already can not use
DNSSEC by not sending the DO bit in the query, as you already not do
yourself in the mozilla products. But at this point, you would be
reducing my security and i will have to disable your privacy feature.

> Requiring query minimization is in keeping with the privacy goal,

Don't make this security versus privacy. Enhance privacy without paying
with security.

> whereas DNSSEC requirements would expand the scope more than we were comfortable with.

I understand your discomfort of still not supporting core fundamental
security technologies that prevent DNS spoofing. It should make you
even more uncomfortable that you are redirecting people to other DNS
servers that might actively support DNS spoofing. Having a policy where
you do not want servers to use RPZ DNS filtering, but not require them
to support the DNS protocol parts that can prove they are not
maliciously modifying DNS, is a policy mistake.

Paul

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 11 Apr 2019 12:53:02 +0200

> We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity.

OK, so privacy: why not consider padding?  Of course, as long as many
webs are without SNI encryption, it's just such a tiny nitpick...
https://tools.ietf.org/html/rfc8467

--Vladimir

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 11 Apr 2019 16:52:38 +0200

Moin!

> How about not discussing application specific design decisions?
Isn’t that the topic of the mailing list (Applications Doing DNS)?

> I don't think anyone suggests it is better to ask unencryped, but when 
> the DoH server you have configured slowly dies or get DoS'ed or 
> whatever, users will appreciate a "way out". In this specific 
> application being discussed, it has a soft-fail mode that works like 
> this.
Yes and me being a user of that application (though not that function) 
thinks that this is bad. I found it odd that most DoH configurations 
I’ve seen by now are singular in what they give as a target, while 
most OS libraries allow multiple DNS server addresses and fail between 
them. Why are you not doing that with DoH?

The first time I saw more than one DoH server used for configuration was 
in draft-ietf-doh-resolver-associated-doh  ( 
https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/ 
) and I think that this is good.

So long
-Ralf
—--
Ralf Weber

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 11 Apr 2019 17:18:31 +0200

> Isn’t that the topic of the mailing list (Applications Doing DNS)? 

It isn't called Firefox Doing DNS, though admittedly Firefox *currently*
seems to be the focus of most discussions.

If Firefox is to be taken mainly as a real-life example on this
mailing-list, is there a suitable Firefox-specific place to discuss
related issues? (Assuming Mozilla is actually interested in that.)

--Vladimir

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Apr 2019 10:41:36 -0500

> related issues? (Assuming Mozilla is actually interested in that.)

Of course your input is welcome. Mozilla is an opensource project, and 
everyone is invited to participate.

For implementation discussions, DoH is part of our networking stack, 
called Necko. Those are discussed on 
https://groups.google.com/forum/#!forum/mozilla.dev.tech.network

For privacy-related discussions, use 
https://groups.google.com/forum/#!forum/mozilla.dev.privacy

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Apr 2019 09:46:03 -0600

Ahoj!

On 4/11/19 9:18 AM, Vladimír Čunát wrote:
> related issues? 

The Networking:DNS component is the one to watch:

https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850

We don't (yet) have a discussion list for "Firefox Doing DNS".

> (Assuming Mozilla is actually interested in that.)

Feedback is always welcome. :-)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Apr 2019 10:02:45 -0600

> More generally, while I understand Mozilla's desire to ensure certain standards to their users, I think it would be better to have a broader definition of what a "good resolver" is, both in terms o…

We (Mozilla) do not want to encourage centralization, which is why we
have published criteria for becoming a trusted recursive resolver within
Firefox. In our conversations with various stakeholders, we have seen a
desire for the kind of industry-wide effort you mention. Although it's
too early to say whether something like that will come together, we are
very much open to discussions exploring that direction.

Peter

---

From: nusenu <[email-masked]>
Date: Thu, 11 Apr 2019 20:26:00 +0000

> https://tools.ietf.org/html/rfc8467

+1 for padding
https://bugzilla.mozilla.org/show_bug.cgi?id=1543811

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Apr 2019 20:34:18 +0000

> Feedback is always welcome. :-)

Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both?

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Apr 2019 14:40:19 -0600

> Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both?

Personally I welcome feedback wherever folks feel comfortable providing
it. The discussion lists that Adam Roach mentioned are also appropriate.

Peter

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Apr 2019 15:50:35 -0500

> Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both?

I think we'd like to prevent the "Applications Doing DNS" list from 
becoming just the "Mozilla Doing DNS" list. To the extent that you'd 
like to engage with a broader slice of Mozilla than just those of us who 
participate in the IETF, I'd encourage you to take Mozilla-specific 
concerns to the mailing lists I pointed to earlier.

You can also comment on bugs in the component that Peter points to, but 
there's a pretty strict policy of "no advocacy in bugs," so you may find 
the mailing lists more satisfying.

This is probably as good a place as any to point to the code of conduct 
for these mailing lists: 
https://www.mozilla.org/en-US/about/governance/policies/participation/

/a

---

From: Brian Dickson <[email-masked]>
Date: Thu, 11 Apr 2019 17:24:23 -0700

> concerns to the mailing lists I pointed to earlier.

Hmm...

I disagree on multiple distinct fronts.
One is "Note Well", whereby all the IETF protections/restrictions are
applied to IETF-hosted mailing lists and all other IETF activities. I
believe there is benefit in keeping this discussion here.

The second is, even if some of these appear to be Mozilla issues, those are
mostly because they're visible (not sure if "first" applies, but it could
as well).

Whatever surfaces here, is valuable to capture here, as a way of helping
inform anyone else that tries to do similar stuff (whether in a browser, or
in any other app) in future.
At a minimum, being able to search this mailing list is probably very
helpful.

The third issue is that whatever is done, might well be appropriate to
"standardize", at least in the sense of establishing expectations for how
any given vendor should do whatever is being done.

Ideally, the outcome could be actual interoperability between apps and some
common "substrate", whether it is implemented as an API, a protocol (if we
can consider "loopback" as qualifying for "on-the-wire" treatment), or a
configuration file or set of files.

Note that DNS itself standardized on the "master file format" for zones,
even though that was one specific implementation of not-on-the-wire data
(plus some metadata?). So, from the DNS perspective, it has significant
precedence which is maintained, including on such things as "presentation
format" (which often is a 1:1 mapping for "master file format").

Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Apr 2019 21:06:31 -0500

On 4/11/19 7:24 PM, Brian Dickson wrote:
>
>
> On Thu, Apr 11, 2019 at 1:51 PM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre
>     <[email-masked] <mailto:[email-masked]>> wrote:

I'll repeat the most important words from my previous message, as your 
response indicates that you skipped over them: "To the extent that you'd 
like to engage with a broader slice of Mozilla than just those of us who
participate in the IETF..."

/a

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 12 Apr 2019 14:51:17 +0200 (CEST)

> Il 11 aprile 2019 alle 18.02 Peter Saint-Andre <[email-masked]> ha scritto:
> 

Well, let's have them :) and I also heard such desire from several people. I guess this kind of effort is not in topic for the IETF; maybe, as for DNSSEC, ISOC and/or ICANN could act as the hosts of a "Do* deployment" initiative that would also discuss the non-technical parts that are missing.

Ciao,
--

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Apr 2019 09:02:31 -0700

Peter Saint-Andre <[email-masked]> writes:

> Firefox.

There are problem with this:

1) Regardless of how many items you have listed, most of your users will
take the default.  Have you considered randomly selecting defaults for
each user?  If they all pass your policy test, then this should be
acceptable?

2) Regardless of how many items you have listed, and which one a
particular user may select, you're still providing centralization from
their point of view.  It doesn't matter how many in the list there are
if all a given users queries still arrive at the same place.  That's
still centralization.  Have you considered randomly rotating all queries
through every item in the list, or turning the list into a series of
checkboxes instead of a single-choice radio dialog to avoid centralizing
my privacy (which suddenly becomes less private)?

-- 
Wes Hardaker
USC/ISI

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Apr 2019 11:14:00 -0600

Hi Wes,

> There are problem with this:

There are always problems. :-)

> take the default. 

We are well (perhaps painfully) aware of this.

> Have you considered randomly selecting defaults for

We have considered this, as Ekr noted in his message on March 27th:

https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw

> still centralization. 

Personally I don't know that most users have a "point of view" regarding
centralization. Definitions might vary, but in my experience many people
think centralization occurs when a given kind of service is provided by
only one or a few entities. If we can build an ecosystem wherein there
are dozens of DoH providers, is that centralization?

> Have you considered randomly rotating all queries
> through every item in the list, 

We've considered random rotation but "there are problems with this".

> or turning the list into a series of
> checkboxes instead of a single-choice radio dialog 

There are non-trivial UX challenges and we're studying how to present
the right options to users.

> to avoid centralizing

The point of defining criteria and policies (with contractual
obligations in place) is to protect user privacy in comparison to the
current state of the world. It's not clear to me why you believe that
your definition of centralization results in degradation of user
privacy, but perhaps you could explain that more fully.

Peter

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Apr 2019 10:54:35 -0700

Howdy,

> We've considered random rotation but "there are problems with this".
So, I assume Wes didn't mean sending all queries to all entities on the
list, because that would be wasteful of bandwidth and very leaky of
information.  I think he meant "random rotation", which is the question you
answered.

But the reality is that folks have been dealing with the DNS round-robin
problem a long time and the change in transport protocols doesn't change
the parameters of the problem that much.  Generally speaking, you are
optimizing for reduced latency.  I think it was Duane Wessels who
introduced the "ladder race" method, which works pretty well over time;
there are also lots of variations of it.

Ladder race works by starting from a list, either with a known default or
no default.  You pick two for the first query and race them.  The winner
becomes the default and is raced against a random member of the list for
the next query or after a period of time--in this case, I'd suggest basing
that time period on the HTTPS set up time (e.g. 5x the set-up time).  Once
you have raced the entire list, you have a resolver choice that has the
lowest latency for that particular client.  You then re-race after a longer
elapsed period of time; if you get the same choice, you lengthen the time
between races.  Every time the race returns the same choice, the signal
that this is a stable choice increases and the time lengthens.  If there is
a change, you drop back to a shorter race time.

What this should do is associate the clients with the lowest latency
resolver.  If a resolver gets busy, its latency will increase and it will
go down in the races and shed clients, so this is a blended signal of
network distance and resolver load.  It will vary over time, but there are
lots of clients for whom that variation won't result in a change in
assigned server.

In this case, you also don't need all the servers to speak the same
protocol; you could blend DoT and DoH servers into the same list.  That
might actually reward the use of DoT where it is not blocked, because the
response time for a cache fill is likely to be a bit better (as there is
less overhead without the mime-type processing in DoH).

Mechanisms like ladder race and its variations basically provide you some
way gathering data to make the choice in a way that optimize what you want;
the key is doing it in a way that is friendly enough to the resolvers and
the network. But I don't think this is a new problem, even if this code is
new to Firefox.

regards,

Ted

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Apr 2019 13:38:02 -0700

Ted Hardie <[email-masked]> writes:

> So, I assume Wes didn't mean sending all queries to all entities on
> the list,

That would defeat the purpose of what I was saying, so yes...  I meant
rotate through them.

> resolver.

I wish we (collectively) could get over the notion that latency was the
only, or the most important metric out there at all times.
Happy-eyeballs approaches to problems can go too far.
-- 
Wes Hardaker
USC/ISI

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Apr 2019 13:51:17 -0700

> Happy-eyeballs approaches to problems can go too far.

The world of browsers cares a lot about latency, since it effects page load
time and thus revenue.  I don't think it is going away as *a* metric, in
other words.  Systems like this also distribute load even among
uncoordinated servers, which is a useful characteristic for both networks
and server operators.

What else do you want to see optimized here?

Ted

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Apr 2019 14:48:20 -0700

Ted Hardie <[email-masked]> writes:

> The world of browsers cares a lot about latency, since it effects page load time and
> thus revenue.  I don't think it is going away as *a* metric, in other
> words.

Nor should it!  It's an important one!  I never tried to say otherwise.

> What else do you want to see optimized here?

Like most "triangle-like" choices, there is likely no perfect balance of
metrics you could pick from and each of us would likely pick different
solution points.

The three big ones that are coming back time and time again are:

1. latency
2. privacy
3. authenticity

Right now, most web-browsers (as you point out) are optimizing for (have
always been in a race for) latency.  Only recently is the desire privacy
actually becoming important enough that there is a desire to use a
slightly slower protocol like DOH to achieve privacy away from
unencypted traffic to access point resolvers/ISPs, and from the access
point resolvers/ISPs.  This, itself, is probably a good trend.

But then you bring in the discussion of DNSSEC and authenticity, which
is the only current way to ensure end-to-end data integrity and combine
this with Martin's statement of

> are improving privacy of browsing activity.

Which clearly shows that between the above three, they're willing to
sacrifice some level of authenticity to achieve better latency and
privacy.  Note, though, that this choice isn't wrong.  It's a choice.  I
may choose a different one, as may others.  And I'm more than sure my
list above is incomplete from an ideological stand point; it just
happens to be the three biggest I could think of.

It would be interesting to put a "pick two" dialog box in front of a
billion users and see what was selected.  Then watch them as the
usability changed and see if when presented the same choice a month
later if they'd stick with their original choice.

-- 
Wes Hardaker
USC/ISI

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Apr 2019 15:16:39 -0700

> On Apr 12, 2019, at 2:48 PM, Wes Hardaker <[email-masked]> wrote:
> 

On the other hand, DNSSEC does not guarantee authenticity either. It guarantees that the mappings of name to IP address is authentic, but that's not the same thing as guaranteeing that the connection actually terminates at the authentic end point. There could well be a NAT somewhere that translates the IP address and delivers the packets to a different server. See for example the many cases of rerouting 8.8.8.8 traffic to a different server.

On the web, authenticity is provided by the server identity verification built in TLS and used by HTTPS. Arguably, once you have HTTPS and authenticate the server, then DNSSEC does not provide any additional guarantee.

What DNSSEC provides is something else. If the name resolution points to the IP address of the wrong server, the TLS authentication will fail, and so will the connection. Falsified name resolution is thus a form of DOS attack, and DNSSEC protects against that. That's nice, but not essential.

Of course, DNSSEC is useful for other scenarios, such as retrieving keys. But these are not quite the main web scenarios.

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Apr 2019 09:20:10 +1000

> On 13 Apr 2019, at 8:16 am, Christian Huitema <[email-masked]> wrote:
> 
> 
> 

And if Mozilla add DANE support then DNSSEC in the DoH server is essential.  DNSSEC requires that *all* servers in the DNS lookup path implement DNSSEC for correct operation (recover from different classes of attack).  DANE can protect against various attacks on the WPKI.

> -- Christian Huitema 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Apr 2019 16:44:18 -0700

Christian Huitema <[email-masked]> writes:

> On the other hand, DNSSEC does not guarantee authenticity either. It
> guarantees that the mappings of name to IP address is authentic, but
> that's not the same thing as guaranteeing that the connection actually
> terminates at the authentic end point. There could well be a NAT
> somewhere that translates the IP address and delivers the packets to a
> different server. See for example the many cases of rerouting 8.8.8.8
> traffic to a different server.

Yes, you're absolutely right.  There are a ton of layers of the protocol
stack that get involved, and attacks at any point along the way can
break the connection so it becomes unusable.  Without DNS security, may
never get to the right place.  Without routing security, you may never
get to the right place.  Without TLS security, you may never get to the
right place.  If you don't type things properly, you may get to the
wrong place.  Protecting all layers increases your odds that you're
getting to the right place.  If you only check the highest layer (and
you trust it implicitly) you still may be misdirected at other layers,
causing client failures that may have been avoidable.

> Arguably, once you have HTTPS and authenticate the server, then DNSSEC
> does not provide any additional guarantee.

That is one view, yes.  As I said in my previous note about other
choices: it's not wrong!  You're prioritizing your needs and tradeoffs,
however, and others may have different prioritization.  Its in this
selection of trade-offs that we seem unable to help users make informed,
personal decisions.

-- 
Wes Hardaker
USC/ISI

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 13 Apr 2019 10:11:28 +0200 (CEST)

> Il 12 aprile 2019 alle 19.14 Peter Saint-Andre <[email-masked]> ha scritto:
> 

It is still centralization if there is a single entity deciding who can run an "accredited" DoH provider, i.e. one that will be actually part of the available choices / rotation set / default for most users. If there can be no other way than having a single entity (or a few entities) doing something for everyone, then you need to get into the realm of building organizational and regulatory machinery that guarantees the public interest (ICANN anyone?). And this is hard and always controversial.

Ciao,
--

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 13 Apr 2019 10:19:15 +0200 (CEST)

> Il 12 aprile 2019 alle 23.48 Wes Hardaker <[email-masked]> ha scritto:
> 
> always been in a race for) latency.  

The policy problem of optimizing only for latency is that in many cases an operator can lower the latency of their service almost at will by throwing more money at it, so if someone has a lot more money to throw than the others and is determined to use it, any algorithm only focusing on latency will always pick their service and you will get full centralization, which is deadly for privacy.

Ciao,
--

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 16 Apr 2019 14:58:52 +0000

Chiming in late on the technical aspects of the policy - and discussion of whether or not to include DNSSEC in the TRR requirements. IMO, Mozilla can lead the way and help spur adoption. Said another way, this is Mozilla's 'sharks with laser beams' moment on DNS security & privacy. ;-) So I'd say require DNSSEC validation as well as native IPv6 support.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 16 Apr 2019 15:08:39 +0000

And for ease of any replies, I have a separate question on CDN localization via ECS. The 6th privacy requirement suggests that ECS cannot be used unless there is encryption between the resolver and the authoritative server, presumably via DoT. This suggests that the privacy concern isn't that the network/geographic hint provided by ECS is problematic in and of itself, but that it should not be observable along the network path used in recursion. 

But if TRR-to-auth recursion is not available via DoT, I wonder what the recommended mechanism is for providing a more privacy-protective network-geographic hint to an authoritative server, in order for example for a CDN to dynamically respond with a localized response. Maybe something new needs to be standardized? What options do folks suggest?

Thanks
Jason

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 16 Apr 2019 17:45:29 +0000

It's kinda like a new "trusted root" program, isn't it?

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Apr 2019 14:20:28 -0400

On Tue, Apr 16, 2019 at 12:00 PM Livingood, Jason <
[email-masked]> wrote:

> And for ease of any replies, I have a separate question on CDN
> localization via ECS. The 6th privacy requirement suggests that ECS cannot
> be used unless there is encryption between the resolver and the
> authoritative server, presumably via DoT. This suggests that the privacy
> concern isn't that the network/geographic hint provided by ECS is
> problematic in and of itself, but that it should not be observable along
> the network path used in recursion.
>
> But if TRR-to-auth recursion is not available via DoT, I wonder what the
> recommended mechanism is for providing a more privacy-protective
> network-geographic hint to an authoritative server, in order for example
> for a CDN to dynamically respond with a localized response. Maybe something
> new needs to be standardized? What options do folks suggest?
>

The "exit IP" of a widely-distributed large-scale resolver service is such
a network-geographic hint, with the level of granularity (and privacy)
depending on the scale and architecture of the resolver service.

I think the question of whether we can improve on ECS is interesting, but I
would encourage you to follow up in DPRIVE or DNSOP, rather than this ADD
list, since that question is equally relevant regardless of whether the
query is originated by an application.

Thanks

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Apr 2019 13:25:31 -0500

> But if TRR-to-auth recursion is not available via DoT, I wonder what the recommended mechanism is for providing a more privacy-protective network-geographic hint to an authoritative server, in orde…

I realize that the kind of change I'm pointing to here would represent a 
significant shift in deployment models, but perhaps some out-of-the-box 
thinking would be useful. The results reported in 
<https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf> 
are very encouraging.

/a

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Apr 2019 14:31:28 -0700

> new needs to be standardized? What options do folks suggest?

That's a great question. Apologies in advance for always providing long
answers. :-)

IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip.

I may be oversimplifying the situation, but I believe the vast majority of
authority DNS services (or proxy services in front of those) structure
their internal representation of things as geo->answer mappings, and
generally have some flavor of ip->geo mapping on their front-end(s).

Those internal representations may be non-standard, but there are standards
for geo representations for country and sub-country levels, e.g. ISO-3166,
with 3166-1 being countries, and 3166-2 being sub-country 3-letter codes.

 I think there is sufficient anonymity in using these codes instead of ECS,
which would remove the need to encrypt the resolver-auth transactions, and
potentially offer other benefits to auth operators which as a consequence,
would potentially improve both the quality of results (by standardizing the
GEO codes, and placing the ip->geo accuracy responsibility onto the
resolver).

There are other ways to improve the whole ECS model by moving to GEO. For
example, a query to an authority server with GEO might return not only an
answer, but also a hint about the granularity at the specific GEO code. A
query for e.g. CA-ON might return an answer for CA-0, indicating that no
more-specific answers within CA are available, while a query for e.g. CA
might return an answer for CA-1 (indicating that more-specific answers are
available, hinting that the resolver might want to ask again). The GEO
stuff could be treated analogous to QNAME minimization; ask for the
next-more-specific answer IFF more-specifics are available.

It would require the resolver to have its own IP->GEO mapping stuff, but
has the benefit of getting consistent results across authority providers
(always right or always wrong, and the resolver has both the ability and
incentive to fix any IP-GEO mapping errors).

It probably helps scaling on the cache side (resolver) and zone side
(authority).

Any authorities doing ECS probably already have the GEO->zone stuff and
possibly even encode it that way; the incremental work in supporting an
EDNS GEO would in those cases be negligible.

Honestly, if GEO can get standardized and reach critical mass, I think it
would be valuable on its own, even without the privacy aspects, and I think
it would be nice to use it and to deprecate ECS, eventually.

Brian.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Apr 2019 14:36:10 -0700

On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <[email-masked]>
wrote:

> Those internal representations may be non-standard, but there are
> standards for geo representations for country and sub-country levels, e.g.
> ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country
> 3-letter codes.
>
>  I think there is sufficient anonymity in using these codes instead of
> ECS, which would remove the need to encrypt the resolver-auth transactions,
> and potentially offer other benefits to auth operators which as a
> consequence, would potentially improve both the quality of results (by
> standardizing the GEO codes, and placing the ip->geo accuracy
> responsibility onto the resolver).
>

I forgot to mention another aspect of this idea: privacy-preserving
iteration. Rather than only querying for the more-specific code associated
with the client, the resolver could just as easily do queries for all of
the next-specific-level entries, possibly in parallel, possibly randomized
order. The resolver would be able to provide an answer to the client once
the particular answer it was looking for was received, and would have the
added benefit of pre-populating its cache for the other
geographically-close answers.

Brian

---

From: "Mark Delany" <[email-masked]>
Date: 16 Apr 2019 21:58:49 +0000

On 16Apr19, Brian Dickson allegedly wrote:

> There are other ways to improve the whole ECS model by moving to GEO.

There are other reasons for using ECS besides GEO and that is
topological proximity and path costs.

While it is true that many are using GEO as a proxy for topology
because it's close enough for their application, e.g:

    if countryCode[ip] == "UK" then serve a London IP.
    if countryCode[ip] == "AU" then serve a Sydney IP.

there are others who use ECS as input into path and cost metrics as
part of calculating an answer.

They do this because latency means everything or costs mean everything
or both! Such calculations fail to work with geo-only data -
particularly if your deployment is more fine-grained than country-code
level.

Mark.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Apr 2019 15:18:57 -0700

> particularly if your deployment is more fine-grained than country-code
Yes, I agree with what you are saying.

That's why I indicated that by "geo", I meant OPTIONALLY more fine-grained
than country-level:

>country and sub-country levels, e.g. ISO-3166, with 3166-1 being
countries, and 3166-2 being sub-country 3-letter codes.

(This may or may not be adequate for some of those currently doing ECS;
however, without GEO, there is no alternative.)

The original question raised by JL was what alternatives there might be to
ECS, that could preserve privacy without requiring encryption?

In general, the existence of two solutions, ECS and GEO, would facilitate
various "consenting adults" to agree on ECS where there is reason to do so.

It might be a bit more data to stuff into a query (either or both of ECS
and GEO), and for the answer returned to indicate which one was used (ECS
or GEO).

But I think that way would support multiple use cases, including encrypted
or not (according to agreements with e.g. browser vendors for inclusion on
some list).

So, "moving" might not mean the same thing for everyone, it is more a
question of "supporting a new standard, with or without supporting an older
standard"..

I'm pretty sure we are not in a one-size-fits-all world here.

Brian

---

From: "Mark Delany" <[email-masked]>
Date: 16 Apr 2019 23:10:16 +0000

> countries, and 3166-2 being sub-country 3-letter codes.

I hope I'm not mis-understanding you, but no level of fine-grained GEO
provides suitable input for topology-based solvers. I want to know
which networks you are connected to and even a high-precision lat/long
doesn't tell me that. Your /24 does.

> I'm pretty sure we are not in a one-size-fits-all world here.

For sure, but fine-grained GEO raises more questions. What if you want
to send sub-country codes to trusted auths to get better resolution
but only country codes to less trusted auths to get better
privacy. How is that provisioned in end-user equipment and kept
current?

The other thing is that auths can play discovery tricks to correlate
queries with client IPs anyway. E.g. issue nonce IPs with very short
TTLs then watch for inbound connections. (Finally a killer app for
IPv6!). So I think we want to be crystal clear about what privacy risk
we think is being solved and whether it's lulling people into a false
sense of security or not.

Mark.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 16 Apr 2019 16:48:36 -0700

On 4/16/2019 11:25 AM, Adam Roach wrote:
>> But if TRR-to-auth recursion is not available via DoT, I wonder what
>> the recommended mechanism is for providing a more privacy-protective
>> network-geographic hint to an authoritative server, in order for
>> example for a CDN to dynamically respond with a localized response.
>> Maybe something new needs to be standardized? What options do folks
>> suggest?
>
>
> I realize that the kind of change I'm pointing to here would represent
> a significant shift in deployment models, but perhaps some
> out-of-the-box thinking would be useful. The results reported in

On a related note, the IETF version of QUIC is including an option to
automatically migrate a client's QUIC connection to a "server preferred
address". This is specifically designed so the initial handshake can
happen through a server anycast address, but the reminder of the
connection goes through a server unicast address specific to the server
site. I short, it will work as long as anycast routing remains stable
for 1 RTT or 2.

-- Christian Huitema

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Apr 2019 16:53:17 -0700

> doesn't tell me that. Your /24 does.

Yes, I understand. For you, ECS works fine, and GEO doesn't.
So, continue to use ECS, and don't use GEO.

I don't understand why that would be a problem, unless resolver operators
choose not to continue to send ECS.

They might make that decision based on the requirements to encrypt
if ECS is used. Or, they may decide doing ECS is worth the encryption cost,
and encrypt and use ECS.
(Those issues would be something for you to take up with them, IMHO.)

Other auth servers might make different decisions on ECS, for whatever
reason.
Those other auth folks might not want to encrypt, and may want to use GEO.
For them, that may be good enough.

Them doing GEO doesn't impact you doing ECS, unless I'm missing something
obvious.

GEO might not be as good as ECS, but there are plenty of cases where the
difference is moot.
E.g. if the zone owner (!= auth operator) has services in only a few
places, and they don't benefit
from any granularity improvement.

> privacy. How is that provisioned in end-user equipment and kept

Don't know, don't particularly care, honestly.
I would expect that to be something managed on a per-auth-provider basis,
or maybe negotiated somehow?

What does "trusted" mean, privacy or something else?

> sense of security or not.

I think that would imply cooperation between auths and those seeking to
defeat the privacy of Do*.
I don't think anything done resolver-auth has the ability to impact that
cooperation, if it exists.

I.e. if an auth does that nonce trick, it doesn't matter whether the
resolver encrypts the connection,
it doesn't matter whether ECS is used or GEO is used. The client's
association is discovered on
the data connection established based on the DNS answer.

Maybe the resolver can implement counter-measures on behalf of clients,
maybe not.
But the issues is invariant over encrypted/clear or ECS or GEO, as far as I
can tell.

In fact, I'd argue the granularity aspect of GEO may provide better "cover"
to clients,
since the recursive could do any number of things for low TTLs that
compensate.
I'm not condoning any particular countermeasure, only suggesting that the
existence
of countermeasures which align better and scale better with GEO, could be
more
effective. Examples might be, requerying and keeping a variety of answer
sets, and
serving them randomly, i.e. a combination of "hammer" and "serve-stale".

Privacy, like security is hard. Trying to mesh efficient/accurate results
with privacy is also hard,
and may require re-thinking solutions.

There may be some need to trade off efficiency with privacy, or to consider
other means
of approaching the solution space for efficiency (with respect to topology).

E.g. maybe instead of GEO, using ASN based mechanisms, which better reflect
topology,
while offering some degree of privacy. Clearly there is non-uniformity,
since some ASNs have
very few prefixes which are small, and others have lots of large prefixes.

Thoughts on this?

Brian

---

From: Geoff Huston <[email-masked]>
Date: Tue, 16 Apr 2019 22:40:09 +0000

> On 17 Apr 2019, at 12:58 am, Livingood, Jason <[email-masked]> wrote:
> 
>  So I'd say require DNSSEC validation

FWIW so would I - securing the channel is not the same as being able to trust the integrity of the content carried in the channel, and for the latter all we have is DNSSEC. The secured channel does allow the client to place slightly more trust in the AD bit in the response.

Geoff

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 17 Apr 2019 09:20:05 +0200

Moin!

> query is originated by an application.
That is correct and there is work in dprive on that. However it is relevant
here as Mozilla has required secure communication between recursive and
authoritative servers, for which we don’t have a standard.

So the question is should applications require something that is not
standardised in any way (and not use something that has been standardised
for over a decade - DNSSEC - but I guess that is a different question)?

So long
-Ralf
—--
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Apr 2019 10:44:11 +0200

> On Apr 16, 2019, at 19:45, Salz, Rich <[email-masked]> wrote:
> 

No, dnssec is the “new” trusted root program. This is about transport privacy only. 

Paul

---

From: Erik Nygren <[email-masked]>
Date: Wed, 17 Apr 2019 09:04:13 -0700

> generally have some flavor of ip->geo mapping on their front-end(s).

Unfortunately, Geo is only one of the dimensions used.  At least some of
the common and heavily used CDNs and other DNS-based routing services also
need to use both ASN and in some cases the regional network location within
the ASN.  As an example, a CDN or other widely distributed service may have
"on-net" deployments located deep within ISP regional networks.  So it's
not just a matter of "hand out the London cluster for UK clients".  It's
"hand out the right cluster in the UK for the client based on the POP for
the ISP/network they are currently connected to, out of a set of well over
a hundred distinct UK clusters."

This level of locality can actually help privacy by reducing the number of
hops and network/country borders that are crossed (and therefore reducing
the chances that the service request flow traffic is crossing surveillance
points).

The purpose of doing this is for increasing user performance, but also
avoiding congested interconnect points.  Decreasing localization here would
result in substantially more traffic crossing ISP backbone and interconnect
links.

Even for country-level, the validity of "geo" is a function of the country
and works better in the US and Europe.  In Asia and South America and other
parts of the world there are many areas within countries (and also between
ISPs).

But the general point stands that the client IP is not what is needed here
by authorities.  Just enough information to know where the client is
topologically within the network.  DNS authorities would actually prefer to
have the coarsest effective granularity here as it increases DNS cache hit
rate.

In IPv6 coarser information is easier to provide via ECS.  For example, a
/48 is generally fine as nothing finer-grained typically differentiates
routing.  IPv4 is much trickier due to fragmentation of the address space.

What I'd suggest as an alternative instead is to look at a "kIP" approach.
ie, to only send information via ECS at a granularity that "makes an
individual appear indistinguishable amongst a set of [k] individuals".
For some context, see a talk from maprg:
https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf

Specifying something for TRR-to-auth recursion like "When ECS is sent to
authorities it should be at a k=100 aggregation (or coarser) level, unless
over an encrypted channel" may provide the desired property?   Having a
revision or new version of ECS that makes this easier to accomplish might
also be valuable.  Since this is generally desirable for caching
efficiency, I suspect that even once a recursive to authoritative encrypted
channel is defined it will still be preferable to send these more
aggregated ECS information.

(Note that there may be IPR in the space around sending non-client-IP
identifiers for ECS.)

Also see for background  a SIGCOMM 2015 paper from a few years back on ECS
measurements from one CDN:
https://www.akamai.com/de/de/multimedia/documents/technical-publication/end-user-mapping-next-generation-request-routing-for-content-delivery-technical-publication.pdf

     Erik

---

From: Joe Abley <[email-masked]>
Date: Wed, 17 Apr 2019 12:19:59 -0400

On 17 Apr 2019, at 12:04, Erik Nygren <[email-masked]> wrote:

> On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason <Jason_Livingood@comcast..com <mailto:[email-masked]>> wrote:
> That's a great question. Apologies in advance for always providing long answers. :-)
> 
> I may be oversimplifying the situation, but I believe the vast majority of authority DNS services (or proxy services in front of those) structure their internal representation of things as geo->answer mappings, and generally have some flavor of ip->geo mapping on their front-end(s).
> 
> Unfortunately, Geo is only one of the dimensions used.  At least some of the common and heavily used CDNs and other DNS-based routing services also need to use both ASN and in some cases the regional network location within the ASN.  As an example, a CDN or other widely distributed service may have "on-net" deployments located deep within ISP regional networks.  So it's not just a matter of "hand out the London cluster for UK clients".  It's "hand out the right cluster in the UK for the client based on the POP for the ISP/network they are currently connected to, out of a set of well over a hundred distinct UK clusters."

That's what I have heard.

My understanding is that for many commercial applications, knowledge of the city associated with a request is not sufficient to meet CDN performance expectations, and that a (city, provider) pair is the minimum information required to produce a response. Many use more.

On the other side, there are ISPs who use different source addresses for different queries originated by their resolvers in combination with the client-subnet option in order to tilt the decision algorithm at particular CDNs to better match them to particular clients.

It's not reasonable to reduce the dimensions available to make the content steering decision and expect the mechanism to be implemented and used. The amount of complexity that is tolerated in order to make this work today is substantial, which ought to tell us something.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Apr 2019 11:16:56 -0700

On Wed, Apr 17, 2019 at 9:04 AM Erik Nygren <[email-masked]> wrote:

>
> On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
>> I may be oversimplifying the situation, but I believe the vast majority
>> of authority DNS services (or proxy services in front of those) structure
> the ASN.

Okay, so I did oversimplify. My bad.

Let's consider what the situation is, for authority servers.

Some (not all, not none) are CDNs. Some (not all, not none) are not doing
ECS at all. Some (not all, not none) are doing ECS, but only using
"vanilla" ECS functionality, via third-party IP->GEO databases/services.

The potential trade-off(s), as I see them, are:

   - possible exposure of privacy information via ECS (as currently is done
   today)
   - possible scaling problems caused by requiring encryption, to
   authorities not doing ECS, or who do ECS but could equally do "GEO"
   - public resolver/browser requirements/agreements imposing changes on
   third parties (encryption)

Given that the driver for these changes is "ADD" (applications doing DNS,
specifically here browsers), I'm interested in whether there are ways of
handling these that can balance those issues.

For example, if the public recursive required that the authority support
encrypted transport before doing ECS, and had the ability to fall back to
GEO over non-encrypted transport, would that be feasible?
The public resolver would probably need to keep track of authority servers
that do/don't support encryption, as an optimization.
If the fall-back didn't ever result in ECS over unencrypted sessions, that
would make it mostly immune to downgrade attacks.
This would also provide for a smooth deployment scheme; this could be logic
deployed even before the resolver-to-auth encryption is standardized, with
no "flag day" required.

Since this suggestion has implications to public resolvers, it clearly
requires buy-in from them, and possibly the blessing of the browser folks
that GEO is acceptable from a privacy policy perspective. Feedback is
welcome and sought.

Thoughts?
Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 17 Apr 2019 14:35:00 -0400

On 17 Apr 2019, at 14:16, Brian Dickson <[email-masked]> wrote:

> Some (not all, not none) are CDNs. Some (not all, not none) are not doing ECS at all. Some (not all, not none) are doing ECS, but only using "vanilla" ECS functionality, via third-party IP->GEO databases/services.
> 

So, to briefly join the threads just as further illustration to what I'm talking about, what you're doing here looks a lot like trying to engineer a solution for people you don't know based on requirements you're guessing at. This seems unlikely to converge on anything useful.

Being able to separate away 99% of the resolution problem in the lifetime of a session ("established phase") into something that can be said not to have any privacy or access control concerns beyond those that already exist in the service being used means that all of the traffic engineering required there can continue to be done behind the curtain, engineered with a full serving of commercial advantage and richly flavoured with special secret sauce. I'm not saying this is without complication or is something that exists today, far from it: but it at least puts the design and implementation in the hands of the service architects who know what they need and, crucially, the details don't necessarily need wide exposure and standardisation.

If there's to be an impact on performance from privacy, e.g. from a less sophisticated (even empty) set of available mechanisms available to do traffic steering at response time, it seems like it'd be really nice for it to be brief (e.g., "initialisation phase").

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Apr 2019 19:16:51 +0000

I propose that this thread could be moved to the DNSOP WG mailing list, where ECS originated. I say this because ECS is a privacy problem for non-ADD and ADD equally, and some uses of ADD (application does DoT to the user's normal external resolver) don't make ECS any worse.

The thread is indeed interesting, but it should probably be had where more developers are watching.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Apr 2019 12:18:06 -0700

On Wed, Apr 17, 2019 at 11:35 AM Joe Abley <[email-masked]> wrote:

> So, to briefly join the threads just as further illustration to what I'm
> talking about, what you're doing here looks a lot like trying to engineer a
> solution for people you don't know based on requirements you're guessing
> at. This seems unlikely to converge on anything useful.
>
>
Actually, on this point, I beg to differ.

What I am trying to do is separate out two or three classes of
problem/solution, and avoiding having a single solution (with more
complexity and cost) imposed on the rest of the DNS authority service
community.

I am very happy to leave the specifics of the "secret sauce" behind the
curtain.

I'm trying to find a way of distinguishing the "secret sauce" folks from
the vanilla flavor folks, prior to the "established phase", so that what
"established phase" looks like might be different (e.g. encrypted or not).

I'm trying to do that distinction, upstream of established phase, for the
benefit of those not using any special sauce, so that the cost of "vanilla"
doesn't rise to being the same as the cost of "special sauce".

And, I am doing this based on the requirements of a substantial portion of
the non-"special-sauce" constituency, that portion of which I represent,
whose  requirements I not only know, but am responsible for.

The fundamental question is, for me, whether it is possible to determine
whether a given authority provider requires encryption, based on the
dependency it has on ECS (so that it can provide "special sauce")
If the authority provider does not require encryption, I would like to
facilitate that, rather than always require authority providers to offer
encrypted transport.

I'm completely open to mechanisms that facilitate this divergence.

There is not yet (AFAIK) consensus regarding requiring
recursive-to-authority encrypted transport, and in the absence of such
consensus, believe it is imperative that both encrypted and unencrypted
transport options be supported.

The resolvers may choose not to send ECS over unencrypted transport, and as
long as that is a supported mode (with whatever mechanisms are required), I
have no problem with resolvers and authority servers doing whatever they
want over their encrypted channels.

(BTW, this isn't to say that we don't also represent a substantial number
of zones that do want ECS. We do, and do want to offer and use encrypted
transport for those.)

I am happy to lead any standardization effort (i.e. doing an internet
draft) for the "geo" alternative to "ecs", and am also happy to let the
"geo" thing go, as long we can discuss whether a "no-ecs, no encryption"
option might be feasible.

The "no ECS requirement" I'm speaking of, represents about 40% of the DNS
zones served globally, who are our customers. That we are one provider with
that customer base isn't as relevant, so much as that there are 40% of the
zones with no need for ECS, and that the interaction between public
resolvers and authority servers should be, IMHO, negotiable with respect to
encrypted transport.

> Being able to separate away 99% of the resolution problem in the lifetime
> of a session ("established phase") into something that can be said not to
> have any privacy or access control concerns beyond those that already exist
> in the service being used means that all of the traffic engineering
> required there can continue to be done behind the curtain, engineered with
> a full serving of commercial advantage and richly flavoured with special
> secret sauce. I'm not saying this is without complication or is something
> that exists today, far from it: but it at least puts the design and
> implementation in the hands of the service architects who know what they
> need and, crucially, the details don't necessarily need wide exposure and
> standardisation.
>

I agree that there is no specific requirement for standardization within
the "special sauce" community. I was hoping that there might be some
interest and value in a standardized "special sauce Lite" over and above
the "special sauce" community. If not, no big deal.

>
> If there's to be an impact on performance from privacy, e.g. from a less
> sophisticated (even empty) set of available mechanisms available to do
> traffic steering at response time, it seems like it'd be really nice for it
> to be brief (e.g., "initialisation phase").
>

I agree whole-heartedly.

I also think that the "initialisation phase" represents one place where
security is extremely important, specifically in validating the identify of
the service end-point. A lot of trust regarding privacy is placed on the
end-point, so it is important that that trust not be misplaced. But I think
that is subject for a separate thread.

Brian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 19 Apr 2019 12:02:42 +0000

> -----Original Message-----
> From: Add <[email-masked]> On Behalf Of Adam Roach
> Sent: Thursday, April 11, 2019 11:42 AM
> To: Vladimír Čunát <[email-masked]>; Ralf Weber
> <[email-masked]>; Daniel Stenberg <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [Add] Mozilla's DoH resolver policy
>
> For implementation discussions, DoH is part of our networking stack, called
> Necko. Those are discussed on

Adam, would discussion of the operational aspects of the TRR program (things like "this is what's expected of participating resolvers") be appropriate for this list or one of the lists described above?

Scott

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Apr 2019 10:54:37 -0500

> Adam, would discussion of the operational aspects of the TRR program (things like "this is what's expected of participating resolvers") be appropriate for this list or one of the lists described ab…

Speaking only for myself [and not in any official role] --

My suggestion would be that you decide what you're trying to accomplish 
and post to one or the other accordingly. If you want to have a 
conversation with other Mozilla contributors about the specific TRR 
policy that Mozilla has adopted, I'd use a Mozilla mailing list. If you 
want to provide input to something that you see the IETF eventually 
publishing, I'd post it here. In the latter case, I would imagine you'd 
talk in more general terms about operational guidance for all 
applications, rather than focusing on suggestions for a single product: 
the chances that the IETF publishes a document that focuses on guidance 
for a single product are vanishingly small.

/a