Subject: [Add] What to do in this potential working group

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Aug 2019 23:01:42 +0300

I’ve been on vacation and doing some other things for the last couple of weeks, and now I’ve been trying to read the mailing list discussions. Not easy!

Let me try another angle into the discussion and see if it’s helpful.

Much of the discussion has been about the conflicts between people’s different use cases or trustworthiness perceptions for different entities. “I trust industry X more than industry Y” or “I need to perform <thing> which conflicts what you’re trying to do prevent <another thing>”. And the various details of performing those <things>.

There’s been not so much discussion about concrete things where IETF can help, or discussion about understanding and agreeing where our agreements and disagreements lie, or where the factual things end and opinions begin.

So how about looking at this first by understanding what kinds of things we might actually agree on, and acknowledging what we disagree on? For instance, I think there are helpful small things that I don’t think are hugely controversial, better discovery mechanisms for instance. Similarly, I don’t think we will find an agreement whether one trusts an ISP more or less than a large Internet company (because it depends, duh). But we might find agreement on some more structural things, such as what factors have an effect, and what good solutions look like. For instance, while we might differ on what services we consider trustworthy, to me it seems obvious that creating a single entity that has access to all users’ DNS queries is potentially very dangerous architecture for the Internet. Too attractive target for governments to tap, for instance. 

We might also agree on principles, such as the ones about user configuration taking precedence over network configuration.

We do disagree on how to handle filtering use cases, enterprise networks, how to deal with CDN localisation and other operational use cases. Some of these things people care deeply about. And we might disagree on what the advice is on split DNS.

In any case, to start with the parts that we possibly do agree on, there is at least a beginning of a list of work items. For instance:

* Improved mechanisms for discovery and selection of encrypted DNS transports
* Best operational practices for running an encrypted DNS transport service (possibly subdivided for the type of deployment, e.g., ISP or global service)
* Recommendation for precedence of configuration mechanisms
* Recommendation that having devices or apps “call home” for every user action to a centralised global service is bad practice and should be avoided

Jari

---

From: Eric Orth <[email-masked]>
Date: Tue, 20 Aug 2019 16:21:46 -0400

On Tue, Aug 20, 2019 at 4:01 PM Jari Arkko <[email-masked]> wrote:

> In any case, to start with the parts that we possibly do agree on, there
> is at least a beginning of a list of work items. For instance:
>

You might have disagreements over when such mechanisms should be used, but
I hope the existence of such mechanisms to provide more options/information
to applications is less controversial.

> * Best operational practices for running an encrypted DNS transport
> service (possibly subdivided for the type of deployment, e.g., ISP or
> global service)
> * Recommendation that having devices or apps “call home” for every user
> action to a centralised global service is bad practice and should be avoided

I think such a recommendation may need to be further scoped and nuanced.
For many specialized devices/apps, calling into a specific centralized
service may be the entire user-obvious purpose of the device/app.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Aug 2019 23:25:56 +0300

> I think such a recommendation may need to be further scoped and nuanced.  For many specialized devices/apps, calling into a specific centralized service may be the entire user-obvious purpose of the device/app.

Yes, of course. (But for the record, I was thinking of only in terms of DNS. But even for that there may be cases where a specific centralised service is used by a specific gadget. I’m just reacting on general purpose Internet appliances and browser-type apps doing this.)

Jari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Aug 2019 01:28:31 -0700

> action to a centralised global service is bad practice and should be avoided

I certainly agree that centralization is not ideal, but this recommendation
needs to be balanced against other values, in this case, having the DNS
queries go to a provider with determined, acceptable, privacy policies --
which, after all, is how we got here in the first place. So, no, I don't
think that this proposed recommendation would be right as-is.

-Ekr

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Aug 2019 10:31:13 +0100

> On 21 Aug 2019, at 09:28, Eric Rescorla <[email-masked]> wrote:
> 
> having the DNS queries go to a provider with determined, acceptable, privacy policies 

Acceptable to whom? And who gets to decide what’s acceptable or not?

There’s a very broad spectrum of possible answers to those questions and the IETF should somehow do its best to accommodate or at least tolerate that diversity. Easier said than done I know...

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 21 Aug 2019 12:43:50 +0200 (CEST)

> Il 20 agosto 2019 22:01 Jari Arkko <[email-masked]> ha scritto:
> 

I am also trying to clear the backlog - still 300+ messages left (though almost half of them seem to come from a single person).

> * Recommendation that having devices or apps “call home” for every user action to a centralised global service is bad practice and should be avoided

I still think that having an agreed write-up of the issues and/or of the use cases, even without any recommendation on how to deal with them, could also be useful. This was the main subject of the original three drafts presented in Prague.

This said, the elephant in the room is the use of DNS as a control surface. The IETF as a community disagrees on whether this should exist or not, but as Patrik pointed out, many sovereign countries have already decided that a control surface has to exist, and the industry is required to provide it (or go to jail). There are also plenty of cases in which end-users themselves ask the industry to provide similar control features to them.

A clear and final agreement on whether the IETF is ever going to work on providing such a control surface in a standard way (either DNS-based or in some other way that is at least as effective as DNS filtering is today), or whether the part of the industry that is required to provide it should work on it somewhere else, would IMHO make the rest of the discussion much more focused.

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Aug 2019 13:55:05 +0300

Ekr,

I fully realise that there will be differences of viewpoints when it comes to the trustworthiness of individual DNS service providers.

But I was trying to make a different point. While we may disagree which provider I’d like to use for the DNS service, I think it would be quite reasonable for us to agree that if all of us put our all our queries in one place (whatever that is) that this causes severe problems:

- That place becomes immensely valuable from a commercial data mining perspective. There’s a risk that it will at least at some point be used for data mining, despite whatever the intentions of the people who set this system up now is.

- That place becomes immensely interesting to for governments to tap. There’s a risk that this tapping is either already happening or will be happening going forward, despite best intentions of the people who set it up or who manage it.

- That places becomes critical infrastructure and a weak point that we do not need in the Internet.

As a result, I would like to suggest that the IETF actually concludes the above and recommends against this practice.

For whatever it is worth, I can understand some motivations for doing something like this e.g. in browsers. Some good reasons and potentially also some not so good reasons. But even with that background, it is difficult for me to imagine a worse act for the Internet than making browsers call home for every action of the user. The privacy impacts for the users are unimaginably bad.

A few years ago we realised that surveillance organisations were looking at people's traffic, and we managed to change the Internet to protect this traffic with cryptographic means. I think it is to think about the next step, and ensure that we don’t create an Internet architecture that puts everyone’s data at central location.

Obviously, encrypted DNS is still hugely important, as are global DNS services. However, the deployment model of using one (or a small number of) providers is just wrong. That would be fixable.

Jari

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 21 Aug 2019 12:44:53 +0000

Let me chime for once in this heated discussion as an individual Internet user: Jari, you are 100% right (except perhaps the order of your list, I would have put the critical part on the top as companies can go bankrupt)

-éric

On 21/08/2019, 12:55, "Add on behalf of Jari Arkko" <[email-masked] on behalf of [email-masked]> wrote:

    Ekr,

    

    

    
    
    Jari

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 05:55:27 -0700

> Acceptable to whom? And who gets to decide what’s acceptable or not?

Who decides now?

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Aug 2019 13:58:03 +0100

> On 21 Aug 2019, at 13:55, Ted Lemon <[email-masked]> wrote:
> 

It appears to be Mozilla. Though perhaps I’ve misunderstood their TRR policy.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 06:02:28 -0700

> It appears to be Mozilla. Though perhaps I’ve misunderstood their TRR policy.

No, I mean assuming you aren’t running Mozilla with DoH enabled.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 21 Aug 2019 13:41:32 +0000

I’d like to point out one other point in the context of centralized data being a drawback: data breaches. Every company is susceptible to them, and centralized data requires fewer breaches to occur in a given time window to gain access to the entire data set. This, unlike the data mining potential, doesn’t require nefarious intent by the data holder.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Eric Vyncke (evyncke) <[email-masked]>
Sent: Wednesday, August 21, 2019 5:44 AM
To: Jari Arkko <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] What to do in this potential working group

-éric

    Ekr,

    Jari

    --
    Add mailing list
    [email-masked]
    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C247f87f759f74ee1a6f708d726356c91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637019883216567214&amp;sdata=chzaUKs41KYywrMc5A352%2ByvtNWAspAKy3tkVz5iT%2Bw%3D&amp;reserved=0

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C247f87f759f74ee1a6f708d726356c91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637019883216567214&amp;sdata=chzaUKs41KYywrMc5A352%2ByvtNWAspAKy3tkVz5iT%2Bw%3D&amp;reserved=0

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Aug 2019 17:36:06 +0300

Yes, that’s right.

Jari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Aug 2019 17:31:10 +0100

Jari,

I understand that this is your opinion and the argument you re making but I
can't say I agree with the overall assessment you are making.

We have a situation now where the DNS is tragically insecure and nonprivate
-- and not really that decentralized -- and we have an opportunity ti make
it more secure at the cost of making it more centralized. In this instance,
I think that's a tradeoff worth considering, while also looking for ways to
minimize centralization.

-Ekr

On Wed, Aug 21, 2019 at 11:55 AM Jari Arkko <[email-masked]> wrote:

> Ekr,
>
> I fully realise that there will be differences of viewpoints when it comes
> to the trustworthiness of individual DNS service providers.
>
> But I was trying to make a different point. While we may disagree which
> provider I’d like to use for the DNS service, I think it would be quite
> reasonable for us to agree that if all of us put our all our queries in one
> place (whatever that is) that this causes severe problems:
>
> - That place becomes immensely valuable from a commercial data mining
> perspective. There’s a risk that it will at least at some point be used for
> data mining, despite whatever the intentions of the people who set this
> system up now is.
>
> - That place becomes immensely interesting to for governments to tap.
> There’s a risk that this tapping is either already happening or will be
> happening going forward, despite best intentions of the people who set it
> up or who manage it.
>
> As a result, I would like to suggest that the IETF actually concludes the
> above and recommends against this practice.
>
> For whatever it is worth, I can understand some motivations for doing
> something like this e.g. in browsers. Some good reasons and potentially
> also some not so good reasons. But even with that background, it is
> difficult for me to imagine a worse act for the Internet than making
> browsers call home for every action of the user. The privacy impacts for
> the users are unimaginably bad.
>
> A few years ago we realised that surveillance organisations were looking
> at people's traffic, and we managed to change the Internet to protect this
> traffic with cryptographic means. I think it is to think about the next
> step, and ensure that we don’t create an Internet architecture that puts
> everyone’s data at central location.
>
> Obviously, encrypted DNS is still hugely important, as are global DNS
> services. However, the deployment model of using one (or a small number of)
> providers is just wrong. That would be fixable.
>
> Jari
>
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 21 Aug 2019 17:57:57 +0100

On 21/08/2019 17:31, Eric Rescorla wrote:
> Jari,
> 
> I understand that this is your opinion and the argument you re making 
> but I can't say I agree with the overall assessment you are making.
> 
> We have a situation now where the DNS is tragically insecure and 
> nonprivate -- and not really that decentralized -- and we have an 
> opportunity ti make it more secure at the cost of making it more 
> centralized. In this instance, I think that's a tradeoff worth 
> considering, while also looking for ways to minimize centralization.

With respect, the DNS operations community doesn't appear to agree with you.

There are perfectly good ways to protect both the privacy and integrity 
of the DNS that don't require that centralization.

Ray

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Aug 2019 18:01:16 +0100

> With respect, the DNS operations community doesn't appear to agree with

No doubt.

> of the DNS that don't require that centralization.

Indeed: this is what I was referring to when I said "ways to minimize
centralization". Specifically, ISPs could commit to strong privacy policies
and join our TRR program.

-Ekr

---

From: Ray Bellis <[email-masked]>
Date: Wed, 21 Aug 2019 18:05:13 +0100

On 21/08/2019 18:01, Eric Rescorla wrote:

> centralization". Specifically, ISPs could commit to strong privacy 
> policies and join our TRR program.

Or Mozilla could embrace DNSSEC and DoT thereby encouraging their 
deployment for the benefit of all internet users...

Ray

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Aug 2019 18:14:57 +0100

> deployment for the benefit of all internet users...

I feel like everything meaningful to be said about DNSSEC has already been
said, so I'll spare people that.

The issue isn't DoH versus DoT. but rather having a connection with an
authenticated resolver with defined privacy policies. DoT (or for that
matter DoH) to an arbitrary network-provided resolver doesn't provide that.

Ekr

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Aug 2019 10:36:38 -0700

Hi Jari,

I'd like to slightly re-cast your point and see if you still agree.  If so,
I think I understand better what the working group might do.  If not, the
discussion may help me personally understand your point.

I think there are several possible threat models here.

The basic threat model that DoT and DoH respond to is lack of
confidentiality from observers on the path.  That is addressed if the
selected resolver implements DoT or DoH and is reachable to the client.*

The second threat model is that a resolver may provide an untrustworthy
answer (e.g. captive portal). The use of DoT and DoH can help with this if
the client device, application, or user selects a trustworthy resolver**
and uses the TLS certificate to verify they have reached that service.

The third threat model is that the use of a single large common recursive
resolver mitigates against attacks which track resolution events at the
authoritative servers (since there are common cached replies), but results
in that large common recursive becoming an attractive target for unsavory
business practices, court orders, and infiltration attacks.  Because of
browser fingerprinting techniques the available information may be larger
for DoH than it would be for other clients.

Your concern is that using DoH as a response to the first and second
attacks is increasing the risks related to the third.  Is that
approximately correct?

If so, I think there are practices that we might develop and recommend
(e.g. selectively sending queries to different trusted resolvers) and some
of those may also touch on the split DNS issue.  My modest experience in
this realm suggests, though, that experiments are the only thing that would
tell you the impact of those practices on latency, correctness, and
leakage.  So I'd want some indication that folks are willing to run those
experiments before taking on that work.

regards,

Ted (as an individual)

*DoH was suggested in part because DoT was commonly getting blocked; I
don't have fresh data, though, on whether this is still the case.
**For whatever value of trustworthy is assigned; this point doesn't rely on
a definition of that being common.

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 10:59:34 -0700

Ted,

Not Jari, but wanted to point out one thing:

On Aug 21, 2019, at 10:36 AM, Ted Hardie <[email-masked]> wrote:
> The second threat model is that a resolver may provide an untrustworthy answer (e.g. captive portal). The use of DoT and DoH can help with this if the client device, application, or user selects a trustworthy resolver** and uses the TLS certificate to verify they have reached that service.

You probably need to define “trustworthy answer” here.  Traditionally, a “trustworthy answer” was the data originally supplied by the zone owner of the domain being looked up. DNSSEC was created to ensure this. However, network operators (e.g., CDNs) playing “stupid DNS tricks”, resolver operators providing filtering, etc. may have changed what is a “trustworthy answer” over the years.

With that said, and assuming you’re using the traditional interpretation of “trustworthy answer”, then DoT/DoH do not ensure a “trustworthy answer.” DoT/DoH provide transport protection. The only way to truly ensure a trustworthy answer is to protect the actual answer. Which is what DNSSEC does.

Regards,
-drc
(Speaking only for myself)

---

From: Alec Muffett <[email-masked]>
Date: Wed, 21 Aug 2019 19:06:17 +0100

On Wed, 21 Aug 2019, 18:59 David Conrad, <[email-masked]> wrote:

> The only way to truly ensure a trustworthy answer is to protect the actual
> answer. Which is what DNSSEC does.
>

Fortunately we do not have to wait for DNSSEC in order to get answers from
the people from whom we wish them supplied, privately and untampered-with,
which is the whole point of DNS over HTTPS.

-a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Aug 2019 11:11:11 -0700

Hi David,

On Wed, Aug 21, 2019 at 10:59 AM David Conrad <[email-masked]> wrote:

> You probably need to define “trustworthy answer” here.
>

I tried to finesse that saying by saying it is up to the client to decide
this.  If there is an objective reality to "trustyworthy answer", though, I
think "true to the data supplied by the zone maintainer" may still be it.
I'm not sure there is, though, if you have any belief in the use of the DNS
as a control surface.  In the case of household using a DNS filtering
service, the answer may be that the "trustyworthy" resolver provides the
data supplied by the zone maintainer after the application of the filters
to which the subscriber has agreed.

>  Traditionally, a “trustworthy answer” was the data originally supplied by
> the zone owner of the domain being looked up. DNSSEC was created to ensure
> this. However, network operators (e.g., CDNs) playing “stupid DNS tricks”,
> resolver operators providing filtering, etc. may have changed what is a
> “trustworthy answer” over the years.
>
> With that said, and assuming you’re using the traditional interpretation
> of “trustworthy answer”, then DoT/DoH do not ensure a “trustworthy answer.”
> DoT/DoH provide transport protection. The only way to truly ensure a
> trustworthy answer is to protect the actual answer. Which is what DNSSEC
> does.
>
>
Evidently I was unclear, sorry.  It doesn't assure you that the answer is
trustworthy; it can assure you have reached the resolver that you intend.
If you trust that resolver (for whatever value of trustworthy you have),
that may help.

Thanks for pointing out the lack of clarity,

Ted
(as an individual)

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 11:17:05 -0700

Alec,

On Aug 21, 2019, at 11:06 AM, Alec Muffett <[email-masked]> wrote:
> On Wed, 21 Aug 2019, 18:59 David Conrad, <[email-masked] <mailto:[email-masked]>> wrote:
> The only way to truly ensure a trustworthy answer is to protect the actual answer. Which is what DNSSEC does.
> Fortunately we do not have to wait for DNSSEC in order to get answers from the people from whom we wish them supplied, privately and untampered-with, which is the whole point of DNS over HTTPS.

As mentioned, this is not the traditional answer for what is “trustworthy” when it comes to DNS data: instead of trusting the zone owner (more specifically, the holder to the zone signing key), you are trusting the resolver operator.

The data is ONLY private between the end user and the resolver operator.  It is NOT private to the resolver operator (something people have been repeatedly pointing out) nor is it private between the resolver operator and the authorities.

Further, you cannot ensure to the end user that the “trusted” resolver operator has not tampered with the data, be it due to court order, internal attack, software bugs, etc.

Again, DNS over HTTPS protects the data channel. It does NOT protect the data.

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Aug 2019 14:26:06 -0400

> said, so I'll spare people that.

Actually, there is one thing you could say about DNSSEC that would help
clarify Mozilla's position.

Basically, without doing validation, a stub resolver can be categorized two
different ways:

   - security-unaware stub resolver
   - security-aware non-validating stub resolver

I think it would be helpful if Mozilla were to state which kind of stub
resolver it will be implementing (security-unaware or security-aware).

In either case, a validating resolver will return RCODE=2 if validation
fails, so I think it doesn't have any practical impact.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Aug 2019 15:03:08 -0400

On Wed, Aug 21, 2019 at 2:17 PM David Conrad <[email-masked]> wrote:

>> The only way to truly ensure a trustworthy answer is to protect the
>> actual answer. Which is what DNSSEC does.
>>
> As mentioned, this is not the traditional answer for what is “trustworthy”
> when it comes to DNS data: instead of trusting the zone owner (more
> specifically, the holder to the zone signing key), you are trusting the
> resolver operator.
>
> The data is ONLY private between the end user and the resolver operator.
> It is NOT private to the resolver operator (something people have been
> repeatedly pointing out) nor is it private between the resolver operator
> and the authorities.
>
> Further, you cannot ensure to the end user that the “trusted” resolver
> operator has not tampered with the data, be it due to court order, internal
> attack, software bugs, etc.
>

It is probably useful to highlight the impact of "local policy", especially
with respect to trust anchors.
For example, it might be the case that a given resolver operator has been
compelled to install (and use) some additional trust anchor(s).

Under that resolver operator's local policy, it is possible that the
validity of a given DNS answer from an authority, only due the use of an
additional trust anchor.

In that circumstance, a validating stub would actually determine that the
DNS answer it received from that resolver is BOGUS.

The resolver operator might not be directly involved in modification of the
DNS answer and signatures. For example, there could be a state actor in the
same jurisdiction as the operator and the respective court. The additional
trust anchor presumably would have been used by the state actor for signing
the substituted data. (This would be analogous to the root CA thing being
used for TLS MITM ongoing somewhere.)

Since a resolver operator's data is mostly cached, and cached based on
DNSSEC validity if they validate, such state actions scale extremely well.
This is a significant reason that DNSSEC was designed from the ground up
for client (stub) validation: trust, but verify.

Note: Having multiple resolver operators to choose from helps this
situation, but ONLY if the stub does local validation, and if the
jurisdictions for those operators was different.  The stub treats the
invalid data as a failure, and uses the other provider. This only occurs if
the failure to validate is detected by the stub, by local validation.

NB: recursive-to-authoritative is not encrypted, and on-path attackers can
modify the data. DNSSEC enables detection of this tampering via validation
on signed data, modulo the trust anchor(s) in use.

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 20:58:13 +0100

HIya,

I think I share Jari's concern on this, perhaps though being
somewhat more sanguine about Mozilla's so far announced plans
and what might flow from those...

> The third threat model is that the use of a single large common recursive

Single or small number. I don't know what might be a good
number for the number of independent, reliable and privacy-
friendly public resolver organisations in the world, nor in
any particular situation. As you say, experiments need to
be done and I hope would  include this as a research question.
(As well as of course comparing hypotheses and findings to
reality as that also changes.)

> attacks is increasing the risks related to the third.  Is that

Perhaps not so much "using DoH" as (over-)concentrating
queries. (And I'm not at all claiming that's the only valid
concern in the ADD space.)

> of those may also touch on the split DNS issue.  

As previously mentioned, trickiness abounds - selecting one
at a time with a duration measured in days would just spread
the same information over more organisations etc.

> My modest experience in
> leakage.  

I agree.

> So I'd want some indication that folks are willing to run those

Mozilla seem willing so far and I'd sure academic researchers
will find this an attractive space to explore (I bet a beer we
see a raft of publications in the next year or so:-). I don't
think I've heard of other DNS operators or large-scale clients
being very active in that regard yet, but it would be good to
hear they were.

I guess partly the above indicates there's a longer-term element
to all this, where we're really far from ready for BCP-like
text. I'm not sure how much time there is though to get that
kind of experimenting done before it'd be moot. In terms of
current venues, pearg seems like a place where some of that
work would fit very well.

Cheers,
S.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Aug 2019 13:10:32 -0700

Hi Stephen,

Once small point:

On Wed, Aug 21, 2019 at 12:58 PM Stephen Farrell <[email-masked]>
wrote:

> queries.

I think it is important for us in this group to focus on areas where there
is protocol work to be done or operational practice to change where it
relates to applications doing DNS.  If you wish to write a document on the
general topic of why over-concentrating queries to the common resolvers is
risky, then I am not sure this is the right group for it.  And I personally
think the risks are actually quite different for DNS over port 53 than for
DNS over DoH or DoT, as the primary risk of observation or active MITM
attacks looms much larger there (and is made much easier when there are
common destinations).

regards,

Ted Hardie
(as an individual contributor)

---

From: Alec Muffett <[email-masked]>
Date: Wed, 21 Aug 2019 21:24:23 +0100

> attack, software bugs, etc.

But you can assure that it is a response from the resolver which you chose
(contracted?) to deal with,  rather than some happenstance resolver.

This latter is a major dent in the typical broad DNS threat model, one
which is glibly underplayed by those who would demand some theoretical and
upcoming "perfection" of trust - eg: DNSSEC - when a "better than extant"
option is already available and ready to be adopted by appropriate clients,
in the form of DoH.

To play with metaphor: Seatbelts won't protect you if your car's petrol
tank explodes or if a meteor lands on it; but that's not an argument to
deride seatbelts. One could attempt to make the argument "we won't need
seatbelts when we have a car which is proof against meteorite strike!" -
but I for one shall still wear them, and where they are not available - for
instance on a bicycle - then I shall not.

Equally: I shall (as available) use DoH, Do53, and perhaps even DoT on
occasion, and I shall look down scornfully upon anyone who suggests that
there is only one true DNS resolution transport.

And I will lobby for DoH as "better than extant, where available" — and not
hold my breath for bolt-ons like DNSSEC.

-a

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 21:41:13 +0100

Hiya,

> Once small point:

I'm honestly not sure if that's a small point or not;-)

> risky, then I am not sure this is the right group for it.

But that wasn't quite what I intended. ISTM clear that having O(1)
TRRs in the world would be over-concentrated. I think it's maybe
equally clear that with a different per-LAN recursive (which is
kinda like today) it'd be extremely hard to authenticate those
as TRR-like entities - so perhaps O(10^7) is too many TRRs. I do
think considering "how many TRR-like things would be good" is a
relevant (research?) question that could affect protocol design
and implementations and deployments.

For example, if there's an answer at all and O(100) were that
answer, that might change how a DoT/DoH client might usefully
spread it's queries over those vs. if the answer were O(10^4).

> And I personally

I agree. (As I said concentration is not the only valid concern.)

Cheers,
S.

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 14:04:50 -0700

Alec,

On Aug 21, 2019, at 1:24 PM, Alec Muffett <[email-masked]> wrote:
> On Wed, 21 Aug 2019, 19:17 David Conrad, <[email-masked] <mailto:[email-masked]>> wrote:
> But you can assure that it is a response from the resolver which you chose (contracted?) to deal with,  rather than some happenstance resolver.

If your interest is ensuring that the DNS data the client is receiving corresponds with what the authority for the domain inserted into the zone, what you are assuring is essentially meaningless, regardless of which resolver you talk to.  Actually, given TRRs would be concentration points, the situation is arguably worse than if you used a happenstance resolver: what would happen if the TRR you contracted with is subject to a court order under seal that requires that TRR to modify responses for particular domains?  How would you know?

DoH is channel protection. Can we please stop suggesting DoH addresses data integrity?

Regards,
-drc

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 14:08:14 -0700

> DoH is channel protection. Can we please stop suggesting DoH addresses

I think the issue is that the various DNS WGs have left DNS unencrypted for
30 years. So, while a lot of these arguments have valid points on both
sides, the results are obvious.

thanks,
Rob

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Aug 2019 00:10:36 +0300

Thanks for your email, Ted. Your questions are useful and can help us understand the situation better.

> The third threat model is that the use of a single large common recursive resolver mitigates against attacks which track resolution events at the authoritative servers (since there are common cached replies), but results in that large common recursive becoming an attractive target for unsavory business practices, court orders, and infiltration attacks.  Because of browser fingerprinting techniques the available information may be larger for DoH than it would be for other clients.
> 
> Your concern is that using DoH as a response to the first and second attacks is increasing the risks related to the third.  Is that approximately correct?

Yes, but only approximately. There are multiple factors at play, one is use of encrypted transport and the other one is the degree of centralisation of users’ queries. And some other factors, such as to what extent various parties can change the situation, what the majority of Internet users will be doing based on defaults, etc.

But the main issue that I have is centralisation of DNS queries to an administratively single entity. This is actually an issue even without DoH, but the potential introduction of new defaults and DoH makes the situation more acute.

I do want to underline that there are obviously great benefits with DoH, and even some benefits with centralised DNS setups. But I’m concerned that if we look from a privacy perspective, the default-to-quad-n setup seems… shall we say suboptimal.

Let me make this a bit more personal. I live in Finland, where there is in practice no or very little DNS filtering. My favourite privacy-sensitive browser will today ask my network/my ISP network for DNS resolution services, and the entire process (at least if cached) is local within organisations that I have a contractual relationship with, and who I trust. Now, imagine that the next version of the browser comes with by-default quad-n/doh setting, and now the browser will be contacting a different server that I have first of all no relationship with, and who is very likely either outside Finland or at least administratively controlled by an entity residing in a five eyes country that Snowden revealed performs extensive and indiscriminate surveillance. I know personally some of the people who run some of the global DNS services and have the highest trust on them. But, even they aren’t immune to laws, governments, and various surveillance techniques. I will have to assume that my queries are being tracked. On *every click* that I do on my browser.

You can imagine that I don’t like that situation. I can of course change my settings, but what about my mom or the million other people living nearby? I would consider such browser behaviour essentially spyware. I realise that I’m using a heavy word; I don't use the word lightly but I think that’s a very reasonable description of what’s actually happening.

But onwards to happier things.

First, wouldn’t it be great if I could get DoH to work with my ISP? What other things would that require than my ISP’s action?

> If so, I think there are practices that we might develop and recommend (e.g. selectively sending queries to different trusted resolvers)

Indeed.

I don’t think the the only answer is default quad-n (or doh). I suspect that there’s others things that could be pursued, if one wanted to preserve privacy, *not* collect huge amount of data, and still want to provide better confidentiality. Starting from not sending to one place but say a collaborative large-ish group of services. Or not sending queries to overseas entities to begin with :-)

> and some of those may also touch on the split DNS issue.  My modest experience in this realm suggests, though, that experiments are the only thing that would tell you the impact of those practices on latency, correctness, and leakage.  So I'd want some indication that folks are willing to run those experiments before taking on that work.

I think step one is recognising that we have a problem. And having willingness to care about that problem. Step two is thinking about potential approaches to mitigating problems. There may be experiments to be run as well in step three, would be happy to see that. At least if that was not happening as a side distraction to keep as IETFers happy while the business world is busy switching the entire Internet DNS to a centralised model...

Note also that my particularly worry is about privacy and surveillance, and I think the filtering/control/split DNS etc issues are complex and will take some time. I think.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 22:13:09 +0100

> addresses data integrity?
IMO you're both right but not quite using super-precise
terminology:-)

DNSSEC provides origin-authentication and data integrity
for DNS answers between the signer and validator.

If the client validates the TLS server cert, DoH provides
TLS-server authentication, confidentiality and data
integrity between the TLS client and server.

So yep, both give data integrity, just differently.

I think that was already said in the recent storm of mail
as well:-)

Cheers,
S.

---

From: Alec Muffett <[email-masked]>
Date: Wed, 21 Aug 2019 22:25:53 +0100

On Wed, 21 Aug 2019, 22:04 David Conrad, <[email-masked]> wrote:

> If your interest is ensuring that the DNS data the client is receiving
> corresponds with what the authority for the domain inserted into the zone,
> what you are assuring is essentially meaningless,
>

Concur; but the thing is, to hammer this point home in really short words:
that is not what I am concerned about.

DoH is channel protection. Can we please stop suggesting DoH addresses data
> integrity?

We are not doing so; in fact at the risk of appearing ad-hominem, I will go
so far as to suggest that you are only pretending that we are talking about
data integrity, because it is the only lever you have available in order to
attempt to attack this channel protection value proposition.

We are talking about channel protection as a value proposition to clients
and applications in the typical threat models which are relevant to them.

We are talking about "Applications Doing DNS".

We are talking about clients and channels.

Data integrity is a matter of DNS infrastructure, both systems and data and
metadata. I propose that it is outside of the scope of this list.

-a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Aug 2019 14:26:42 -0700

Hi David,

> DoH is channel protection. Can we please stop suggesting DoH addresses
At least what I've been trying to say is that it gives you on-path
confidentiality and authentication.  You can confirm to whom you are
connecting, and no one has access to the query/response stream by virtue of
being on-path.

That authentication is different from "data integrity" of the data being
sent and I recognize that it is different.   But it is nonetheless
something that folks would like to see, especially in the case where they
have a reason to believe that party has a policy aligned with their own
(e.g. parental controls).

My apologies for any lack of clarity,

Ted

---

From: Adam Roach <[email-masked]>
Date: Wed, 21 Aug 2019 16:27:15 -0500

On 8/21/19 4:10 PM, Jari Arkko wrote:
> Now, imagine that the next version of the browser comes with by-default quad-n/doh setting, and now the browser will be contacting a different server...

I really wish people wouldn't persist in ignoring repeated explanations 
that Firefox (at least) will have actual user interaction at the time 
that DoH is made available in a user's region, with a one-click option 
to turn it off. Theoreticals that presume DoH will be activated silently 
imply a level of incompetence and/or malice on behalf of Mozilla's 
product managers that I don't believe is warranted.

If there's any progress to be made, it almost certainly requires us to 
limit the discussion to situations that may realistically arise rather 
than hypothesizing worst-case scenarios that won't.

/a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Aug 2019 14:28:06 -0700

Alec,

On Wed, Aug 21, 2019 at 2:26 PM Alec Muffett <[email-masked]> wrote:

>
> We are not doing so; in fact at the risk of appearing ad-hominem, I will
> go so far as to suggest that you are only pretending that we are talking
> about data integrity, because it is the only lever you have available in
> order to attempt to attack this channel protection value proposition.
>
>
Please do not impugn the motives of other members of the list.  That's
damaging to the exchange of ideas, and inappropriate behavior to our
colleagues.

regards,

Ted

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 14:28:41 -0700

Stephen,

> integrity between the TLS client and server.

"TLS client and server" != "signer and validator”

> So yep, both give data integrity, just differently.

No.

What you say would be true ONLY if the DoH client connects to the authoritative source of the data. Which, of course, it doesn’t.

Again, what would happen if the TRR you contracted with is subject to a court order under seal that requires that TRR to modify responses for particular domains?  How would you know?

Regards,
-drc

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 14:31:13 -0700

> damaging to the exchange of ideas, and inappropriate behavior to our

I must agree, even though I agree with Alec on this issue. It seems easy
enough to investigate what actual software and hardware does, and make
points that way.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 22:39:10 +0100

Hiya,

On 21/08/2019 22:28, David Conrad wrote:
>> DNSSEC provides origin-authentication and data integrity for DNS
>> answers between the signer and validator.
>> 
>> TLS-server authentication, confidentiality and data integrity
>> between the TLS client and server.
> 

Yes. That was part of my point.

>> So yep, both give data integrity, just differently.

Sorry, but yes:-)

> 
> What you say would be true ONLY if the DoH client connects to the
> authoritative source of the data. Which, of course, it doesn’t.

Disagree. Data integrity is a security service that can be
provided via digital signatures (in the DNSSEC case) or
via message authentication (use of an AEAD in the TLS case).
Please see RFC4949.

> 
> Again, what would happen if the TRR you contracted with is subject to
> a court order under seal that requires that TRR to modify responses
> for particular domains?  How would you know?

That's a good question but not relevant when considering
whether DNSSEC or TLS provide data integrity in the sense
of a cryptographic protocol. Both do that.

If you want to talk about data integrity in the sense of
"answer faithfully matches the zonefile equivalent content"
then that's possibly a confusing term to use in this case.
It may have been used historically amongst DNSSEC folks,
not sure, but certainly once TLS is in the mix, it'd be
better to call that another thing. That is what I meant
by origin authentication + data integrity though.

Anyway point is: yes, TLS does provide data integrity
for an entirely reasonable definition of the term. And
so does DNSSEC. But they do different things.

Cheers,
S.

> Regards, -drc

---

From: Alec Muffett <[email-masked]>
Date: Wed, 21 Aug 2019 22:41:40 +0100

> damaging to the exchange of ideas, and inappropriate behavior to our

In which case I shall withdraw that comment and replace it with an allusion
to the author's inability to address the argument at hand, for reasons that
are unclear.

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 14:43:17 -0700

Rob,

On Aug 21, 2019, at 2:08 PM, Rob Sayre <[email-masked]> wrote:
> On Wed, Aug 21, 2019 at 2:05 PM David Conrad <[email-masked] <mailto:[email-masked]>> wrote:
> I think the issue is that the various DNS WGs have left DNS unencrypted for 30 years.

No. The fact that the requirements for the DNS protocol transport did not include confidentiality is _an_ issue, not _the_ issue.

Asserting DoH does something that it doesn’t isn’t helping address that particular issue.

Regards,
-drc

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Aug 2019 22:43:39 +0100

> On 21 Aug 2019, at 22:13, Stephen Farrell <[email-masked]> wrote:
> 
> IMO you're both right but not quite using super-precise terminology:-)
> 
> ...
> 

If we’re being super-precise, that’s not quite right either Stephen. :-)

DNSSEC and DoH/DoT are not different paths to the same end goal of data integrity. They provide different flavours of data integrity.

DNSSEC validation means you get the truth, the whole truth and nothing but the truth regardless of your choice of resolver or the transport path between you and that resolver. DoH and DoT offer no protection at all from a lying resolver - you’re just guaranteed to receive precisely whatever lies or truth that resolver sends. So in effect you somehow decide to “trust” a TRR and hope for the best. In some cases, that may well be good enough. In others, perhaps not.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 14:46:09 -0700

On Wed, Aug 21, 2019 at 2:43 PM David Conrad <[email-masked]> wrote:

>
> No. The fact that the requirements for the DNS protocol transport did not
> include confidentiality is _an_ issue, not _the_ issue.
>

Let's dive deeper on that assertion. Why did you write this message?

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 22:47:51 +0100

Hiya,

> If we’re being super-precise, that’s not quite right either Stephen.

Happy to have a definitions-at-dawn duel later... after a
pile of beers some time perhaps:-)

> 
> DNSSEC and DoH/DoT are not different paths to the same end goal of
> data integrity. They provide different flavours of data integrity.

I don't agree that the goals are precisely the same as the
actors involved in providing the security services differ.
There's a lot in common, but they aren't identical.

> DNSSEC validation means you get the truth, the whole truth and
> nothing but the truth 

Phrases such as that don't occur in RFC4949. That's where
we find definitions for these kinds of security service. I
can think of many reasons why it's a good idea to avoid
such phrases when defining technical terms:-)

Cheers,
S.

> regardless of your choice of resolver or the
> transport path between you and that resolver. DoH and DoT offer no
> protection at all from a lying resolver - you’re just guaranteed to
> receive precisely whatever lies or truth that resolver sends. So in
> effect you somehow decide to “trust” a TRR and hope for the best. In
> some cases, that may well be good enough. In others, perhaps not.
> 
> 
>

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2019 15:14:51 -0700

Stephen,

> There's a lot in common, but they aren't identical.

You appear to be agreeing with Jim.

DNSSEC provides data integrity _for what the zone authority put into the zone_, regardless of how it gets to the client.

A TLS channel between a client and a resolver (DoH or DoT) provides data integrity and confidentiality (and _resolver_ origin authentication)  _for what the RESOLVER chooses to serve_.

DoH _will not help_ if the “trusted” resolver is compromised to modify the response (something I suspect concentrating the resolver function will encourage).  DNSSEC would help that particular attack.

My response to Ted that caused me to get sucked into this particular swamp (something I already regret) was merely trying to point out there is a significant difference there.

I hope that clarifies.

Regards,
-drc

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 15:18:56 -0700

On Wed, Aug 21, 2019 at 3:15 PM David Conrad <[email-masked]> wrote:

> My response to Ted that caused me to get sucked into this particular swamp
> (something I already regret)
>

Is that the swamp where the only significant DNSSEC providers are Google
and Cloudflare?

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 23:27:47 +0100

Hiya,

On 21/08/2019 23:14, David Conrad wrote:
>>> DNSSEC and DoH/DoT are not different paths to the same end goal
>>> of data integrity. They provide different flavours of data
>>> integrity.
>> 
>> I don't agree that the goals are precisely the same as the actors
>> involved in providing the security services differ. There's a lot
>> in common, but they aren't identical.
> 

I often do :-)

> DNSSEC provides data integrity _for what the zone authority put into
> the zone_, regardless of how it gets to the client.
> 
> A TLS channel between a client and a resolver (DoH or DoT) provides
> data integrity and confidentiality (and _resolver_ origin
> authentication)  _for what the RESOLVER chooses to serve_.

Yep.

> DoH _will not help_ if the “trusted” resolver is compromised to
> modify the response (something I suspect concentrating the resolver
> function will encourage).  DNSSEC would help that particular attack.

Yep.

Those are both true statements. There are equally true
statements that'd demonstrate cases where DoH or DoT do
better than DNSSEC - IIUC an important one being: given
the (unfortunate) relative sparsity of DNSSEC signed
data, the data integrity service that DoH or DoT can
provide could well be argued to be as good as what a
client can get via DNSSEC when the full set of queries
a client makes are taken into account. I'm not saying
I agree with that as a winning-argument, but it is an
entirely arguable proposition.

> My response to Ted that caused me to get sucked into this particular
> swamp (something I already regret) was merely trying to point out
> there is a significant difference there.

Sure. But I figure its important we try be precise in how
we talk about those differences - given how controversial
people find this topic, we otherwise end up making a hard
discussion harder, as was evident in some recent exchanges.

Cheers,
S.

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2019 21:08:48 -0400

In article <[email-masked]> you write:
>I still think that having an agreed write-up of the issues and/or of the use cases, even without any recommendation on how to deal with them, could also be useful. This was the main
>subject of the original three drafts presented in Prague.

Agreed.  We're still seeing people argue with unstated assumptions that are obviously not the same.

For example, a bunch of messages have gone by that clearly assume that
the person using a device has chosen to use a particular DoH service.
I can easily believe that could be the case for the very atypical
bunch of people in this discussion, but not for grandma using whatever
defaults her browser or phone app or ISP or malware set, nor for IoT
devices that use whatever.

I see similar cross assumptions in "trustworthy result."  Some people
apparently assume it's synonymous with DNSSEC validated, but for me if
it's a bot trying to find its C&C host, the trustworthy result is
NXDOMAIN or SERVFAIL.

I think it would be useful to try and tease these out so we at least
have a chance of agreeing on what we disagree about.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Aug 2019 23:31:22 -0400

> On Aug 21, 2019, at 6:27 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> a client makes are taken into account.

Actually, no, it cannot, at least if the only trust anchor on the DNSSEC validation is the ICANN/IANA root trust anchor.

The protection of data integrity is almost entirely a dependency on whether the resolver validates DNSSEC or not.

If the resolver does not validate, then the resolver is in an unknown data integrity situation for DNSSEC signed zones. Use of DoT/DoH to such a resolver does not change anything. It is strictly garbage in, garbage out (or clean data in, clean data out if no data tampering was attempted). DoX neither elevates nor lowers the integrity of the data compared to the original zone data. NB: If the incoming DNS data was altered, the adversary succeeds EVEN IF THE DATA WAS DNSSEC SIGNED.

Comparing against anything other than the original zone data is meaningless (with the exception of filtering services, which is relevant only if the client opted in to using a resolver that does such.)

A non-DNSSEC zone is basically fair game, irrespective of any validation or channel security. In addition to on path attackers, unsigned zones can be attacked at the resolver by off-path adversaries. They are also susceptible to local attacks on the resolver server itself, and to malicious activity by insiders. 

A DNSSEC signed zone validated by the DNS end client is immune to all of these attacks, reducing otherwise successful attacks to DOS.

If the resolver does validate, DoT/DoH adds nothing at all to the data integrity state.

Here is where it is fair to compare DoX to DNSSEC: From a validating resolver to a client.

The data integrity starts in a known state on the validating resolver.

DoX prevents changing the data integrity via channel security.

DNSSEC “prevents” changing the data integrity via cryptographic signatures which prevent tampering by detection of tampering.

(Both DoX and DNSSEC are susceptible to DOS by an on-path adversary.)

In summary:
If the resolver validates DNSSEC signed data, DoX and client DNSSEC validation have exactly the same protection against tampering.
If the resolver does not validate DNSSEC signed data, a DNSSEC validating client can still detect tampering and protect itself, whereas DoX does not and cannot.

If the data is not DNSSEC signed, the only path component protection occurs between the resolver and client.

A risk analysis of DNS vs tampering would show the place to attack DNS is not on the client side, but rather on the authority side. The reason is that a single successful attack impacts ALL clients rather than a single clients. This also means the more clients a resolver has, the more valuable it is to an attacker.

As to the perceived value of DNSSEC based on how many domains are signed, there is more to this than numbers or percentages.

The flaw is in treating all domains as equally valuable, rather than weighting those values.
You can get to a very high percentage of aggregate value with a small number of zones, if the small number are particularly important, like all of the Fortune 500 or all national governments or a significant portion of critical infrastructure or a combination of those.

And in particular, the value to the individual domain owner doing DNSSEC is ignored in use of raw numbers alone. The value of DNSSEC to joes-bait-shop.hosted-dns.example.com is likely a lot less than iana.org or whitehouse.gov (I’m guessing).

A large bank or government department, for examples, is probably already using DNSSEC. Clients who neither use a validating resolver nor do client-side validation are failing to protect themselves.

Even if the raw numbers are not so great today, if they improve drastically (eg up to 40% of all of DNS zones) in 2020, IMHO it behooves us to not reject those protections, which the domain owners themselves have selected; architectural and operational decisions should be being made in a manner compatible with DNSSEC validation.

Remember, the signing in DNSSEC is not done by the resolver operators, it is done by domain owners themselves (or parties to whom they have outsourced this).

Brian

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 22 Aug 2019 07:52:21 +0200

> The second threat model is that a resolver may provide an untrustworthy answer (e.g. captive portal). The use of DoT and DoH can help with this if the client device, application, or user selects a…

This is resolved by having DNSSEC validation in the client.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 22 Aug 2019 07:54:37 +0200

> Fortunately we do not have to wait for DNSSEC in order to get answers from the people from whom we wish them supplied, privately and untampered-with, which is the whole point of DNS over HTTPS.

Only if you do DNS over HTTPS directly to an authoritative DNS server.

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 23:01:40 -0700

On Wed, Aug 21, 2019 at 10:55 PM Patrik Fältström <paf=
[email-masked]> wrote:

> > Fortunately we do not have to wait for DNSSEC in order to get answers
> from the people from whom we wish them supplied, privately and
> untampered-with, which is the whole point of DNS over HTTPS.
>

Won't the client use the DNS information to make a request over TLS?

If you doubt the security of that, you are questioning the entire global
PKI. I happen to think that infrastructure is a joke, but I do agree that
it foils common criminals and overzealous local administrators.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Aug 2019 07:43:50 +0100

On Wed, Aug 21, 2019 at 7:26 PM Brian Dickson <[email-masked]>
wrote:

>> I feel like everything meaningful to be said about DNSSEC has already
>> been said, so I'll spare people that.
>>
>
> Basically, without doing validation, a stub resolver can be categorized
> two different ways:
>

Are these defined somewhere? If so, can you send a pointer?

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 22 Aug 2019 16:51:36 +1000

On Thu, Aug 22, 2019, at 16:44, Eric Rescorla wrote:
> > Basically, without doing validation, a stub resolver can be categorized two different ways:
> >  * security-unaware stub resolver
> >  * security-aware non-validating stub resolver
> > I think it would be helpful if Mozilla were to state which kind of stub resolver it will be implementing (security-unaware or security-aware).
> 

https://tools.ietf.org/html/rfc4033#section-2

I think that we've implemented the former.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Aug 2019 08:00:21 +0100

On Wed, Aug 21, 2019 at 10:43 PM Jim Reid <[email-masked]> wrote:

> DNSSEC and DoH/DoT are not different paths to the same end goal of data
> integrity. They provide different flavours of data integrity.
>

This I agree with.

> DNSSEC validation means you get the truth, the whole truth and nothing but
> the truth regardless of your choice of resolver or the transport path
> between you and that resolver. DoH and DoT offer no protection at all from
> a lying resolver - you’re just guaranteed to receive precisely whatever
> lies or truth that resolver sends. So in effect you somehow decide to
> “trust” a TRR and hope for the best. In some cases, that may well be good
> enough. In others, perhaps not.
>

I'd like to push on this slightly, if I may.

I certainly agree that from a cryptographic perspective, DNSSEC allows you
to evaluate whether or not the records that you receive are those which
were provisioned (modulo typos, key expiry, etc.). However, as has been
observed here a number of times, there are many cases where the resolver
desires to elide certain records (e.g., for malware filtering) or to
redirect you to some other location (e.g., captive portals). So from a
systems perspective it seems like things are more complicated. Suppose that
I receive a bogus response to my A record query, how am I to usefully
distinguish "this is malware blocking" from "this resolver is malicious"?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Aug 2019 08:05:43 +0100

On Thu, Aug 22, 2019 at 7:52 AM Martin Thomson <[email-masked]> wrote:

> > > I think it would be helpful if Mozilla were to state which kind of
> stub resolver it will be implementing (security-unaware or security-aware).
> >

Yes, this seems right.

-Ekr

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Aug 2019 10:16:51 +0300

Adam,

> I really wish people wouldn't persist in ignoring repeated explanations that Firefox (at least) will have actual user interaction at the time that DoH is made available in a user's region, with a one-click option to turn it off. Theoreticals that presume DoH will be activated silently …

Thanks for this. I did not know that there was a user interaction. (Is there a pointer to go read more of the details of the plan?)

However, I did not presume that there’d be no way to turn this off. Glad to hear the turn of knob is easy though.

But at the end of the day, there are two groups of users… those that will fine-tune their settings (and I’m glad that’s possible on Firefox), and those that will accept the default settings. The latter group may get notifications about things, but they are unlikely to do anything else than to accept the recommended default option. Or understand what the implications of the different options are. My mom will be in this group, and I care about what privacy settings she gets.

> imply a level of incompetence and/or malice on behalf of Mozilla's product managers that I don't believe is warranted.

I’m sorry if this was inferred. For what it is worth, I believe everyone is acting with the best intents. And are very respected experts about the complex situation. However, I think the analysis of the situation in this case has stopped short, and the implications are more dire than people thought, as outlined in previous emails. That’s ok though, the purpose of our discussions is to learn and improve. I’m happy I learned something from your email.

Jari

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 22 Aug 2019 09:24:57 +0200 (CEST)

On Thu, 22 Aug 2019, Jari Arkko wrote:

> they are unlikely to do anything else than to accept the recommended default 
> option. Or understand what the implications of the different options are. My 
> mom will be in this group, and I care about what privacy settings she gets.

This argumentation assumes that the "default" your mom should get is the 
default that is dictated by the coffee shop owner whose wifi she connects to. 
I don't think that's a given. I don't think DHCP is a default that we must 
live with until the end of times.

Privacy? Which is better? Do53 to a server handed out over DHCP or DoH to 
another server? There's not a single answer to this, it depends on who you are 
and what you believe in.

-- 

  / daniel.haxx.se

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Aug 2019 10:57:17 +0300

Daniel,

I agree of course that there are different situations, and that in some cases DHCP default is the wrong option as well. I know in my mom’s case it would have been the right answer, however. But the architectural point I wanted to raise was that regardless of the differences in any specific selection of a server, there seems to be a clear downside to having everyone select the same server. The data source that this creates is far too valuable to be put in one place.

I do have another point as well. We’re not limited to two options — there’s more choice than “trust your network/evil-local-dns-filter” and “trust the quad-n/large-content-provider/nsa”. If people really are serious about improving security and privacy, how about, for instance, creating a collaborative group of content providers, ISPs, and other organisations that wish to provide clean, unfiltered, and not commercially mined DNS service, and have clients use that in some distributed fashion?

I’m obviously handwaving the solution a bit, but my point is — if we want to make an improvement, then it should be an incumbent on us to do a full solution. Shipping my mom’s queries to a single entity /w possible risk of surveillance and other leaks is a recipe for insufficient design, IMHO. If we want an improvement, sell me a solution that I actually want, one that does improve my privacy and resilience against filtering.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Aug 2019 09:41:30 +0100

Hiya,

I agree with the overall thrust of your mail that a fair
analysis of the efficacy of the DNS data integrity services
provided by DoT/DoH vs. what's provided by DNSSEC, in the
real DNS... is complex.

I would quibble with a bunch of things you said but it's
probably better I try resist the temptation, so I'll limit
myself to one, for illustration - I'm not at all trying
to claim this is "the important bit" you missed, just
emphasising the subtlety here:

On 22/08/2019 04:31, Brian Dickson wrote:
> A risk analysis of DNS vs tampering would show the place to attack
> DNS is not on the client side, but rather on the authority side.
Some attackers don't want to be easily noticed, and for
them, it can be better if they tamper more locally.

Again, I'm not disagreeing with your overall message but
rather agreeing about the complexity here. I think a
consequence that follows from that is that anyone making
claims that there is one simple difference between use of
DoH/DoT and DNSSEC is mistaken, and further that it doesn't
really make sense to say one is "better" than the other,
when it comes to providing data integrity.

Personally, when it comes to data integrity of both forms,
I want both and more of both, and I think that is a pretty
defensible conclusion.

Note: the conclusion above only considers data integrity
services. It does not ask anyone to reach a conclusion
about how DoT/DoH might lead to over-concentration of
queries.

Cheers,
S.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Aug 2019 10:37:15 +0100

> spread it's queries over those vs. if the answer were O(10^4).

There's a possible scaling issue here.

To allow efficient use of CDNs it is necessary for some form of client 
geo-location to occur.   It's already been observed in the Samknows 
report[1] that Cloudflare's lack of support for EDNS-Client-Subnet [2] 
(RFC 7871) leads to suboptimal performance when accessing non-CF hosted 
content.

If every network has a "nearby" recursor (whether that be using normal 
DNS, or DoH) then ECS is not required becase the IP address of the 
recursor serves as a good proxy for that of the client.  In that sense, 
O(10^7) is a good thing.

However, RFC 7871 envisaged that the ECS option would only be exchanged 
between consenting servers.   It also says "it is expected that only a 
few Recursive Resolvers will need to use ECS" and alludes to ECS only be 
exchanged on specific agreement between recursive operators and 
authoritative operators.  At the moment we're about O(5) global DNS 
operators, and O(30) major CDNs.

But, if you're talking about getting to the O(100) scale of TRR 
operators all of whom are receiving queries from clients all over the 
world then that's a lot of bilateral agreements and configurations that 
would need to be set up, and a lot of ECS meta-information buzzing 
around the network.

Ray

[1] https://samknows.com/blog/dns-over-https-performance

[2] Cloudflare use Anycast for their CDN instead of "stupid DNS
     tricks", so they don't need ECS.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 22 Aug 2019 09:51:38 +0000

Hello Stephen, others.

> spread it's queries over those vs. if the answer were O(10^4).

I know where you want to get at, but due to the properties of the Big-O 
notation, O(1), O(10^7), O(100), and O(10^4) are all the same (because 
they are all constants, and constant factors are eliminated in Big-O 
thinking). Please check your sources if you don't remember this, or 
never have had the chance to study it. I can suggest sources if necessary.

If you want to say "about 1" or "about 100", then ~1 or ~100 or so may 
be appropriate.

In order (sic!) for Big-O notation to become useful, we have to assume 
we have a number of /n/ clients. Then, sensible answers involving Big-O 
notation may be O(n^0.5) or some such. O(n^0.5) would mean that a 
reasonable number of "TRR-like things" would be on the order of the 
square root of the number of clients.

Of course I have no idea whether it would be O(n^0.5) or O(n^0.1) or 
O(log n) or any other kind of order. A first guess will put the result 
between 1 (not O(1)) and O(n), but that's obvious and not very useful. 
However, there should be people who understand the theoretical 
framework(s) that may give more precise answers. And there should be 
people who know how to design and run experiments to get some more 
precise ideas.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Aug 2019 11:02:32 +0100

> If you want to say "about 1" or "about 100", then ~1 or ~100 or so may 

I was indeed guilty of misusing big-O notation and yes
the above was what I meant.

Thanks,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 22 Aug 2019 12:13:10 +0200 (CEST)

> Il 21 agosto 2019 20:11 Ted Hardie <[email-masked]> ha scritto:
> 
> I tried to finesse that saying by saying it is up to the client
> to decide this. If there is an objective reality to "trustyworthy
> answer", though, I think "true to the data supplied by the zone 
> maintainer" may still be it. I'm not sure there is, though, if 
> you have any belief in the use of the DNS as a control surface. 
> In the case of household using a DNS filtering service, the
> answer may be that the "trustyworthy" resolver provides the data 
> supplied by the zone maintainer after the application of the 
> filters to which the subscriber has agreed.

This was actually the subject of a thought exercise that I presented at ICANN's DNSSEC workshop in Kobe in March ( https://static.ptbl.co/static/attachments/200613/1552292990.pdf?1552292990 ).

IMHO, possibly we have to change (or we already changed, in many people's minds) our understanding of the DNS from a "dumb" global distributed database to a "smart" application-layer traffic control system for the Internet, which indeed will direct you to different resources depending on who and where you are and on a number of policy and technical considerations. In this scenario, trust derives from the resolver you use, and not directly from the ICANN root.

If we got rid of the idea that there is just one correct answer for each given query - something that has ceased to be true for quite a while anyway - we could collectively optimize the DNS for the actual current scenario, which also includes the use of the DNS as a control surface and as a content distribution management system.

--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Aug 2019 11:26:54 +0100

On Thu, Aug 22, 2019 at 8:57 AM Jari Arkko <[email-masked]> wrote:

> I’m obviously handwaving the solution a bit, but my point is — if we want
> to make an improvement, then it should be an incumbent on us to do a full
> solution.

This is not a standard we apply anywhere else in the IETF. Rather we strive
for incremental improvement. I certainly agree that your proposal has
merit, and if you have a concrete way of going about it, rather than just
handwaving about how someone else should do it, let's talk.

Shipping my mom’s queries to a single entity /w possible risk of
> surveillance and other leaks is a recipe for insufficient design,

I agree that there is a risk, but given that we know that the current
design *also* has a high risk of surveillance and other leaks, and that in
fact those sorts of things regularly occur, this doesn't seem to me to be
anywhere near as strong an argument as you seem to think it is.

> IMHO. If we want an improvement, sell me a solution that I actually want,
> one that does improve my privacy and resilience against filtering.
>

Our view is that TRR will do so. You obviously have a different opinion,
and as Adam said, at least in Firefox, you will be able to make that choice
for yourself.

-Ekr

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 22 Aug 2019 13:12:11 +0200

Moin!

> and join our TRR program.
A lot of ISPs have way stronger privacy policies then the TRR program, yet
they can not join because it’s impossible to fulfil the other requirements
and IMHO bad decsisions in the TRR program what to require and what not:
- No DNSSEC
- But qname minimisation that breaks stuff and for larger resolvers adds
not much
- Requirement to publish block lists

So long
-Ralf
---
Ralf Weber

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 22 Aug 2019 13:28:31 +0200

Moin!

On 22 Aug 2019, at 0:18, Rob Sayre wrote:

>> swamp
I assume you are talking about validating recursive resolvers here. 
There are
way more, e.g Comcast, all the swedish ISP, a couple of ISPs in South 
America
and I know that there are more European ISPs that are planning to turn 
it on.

Plus even without validation in the recursive resolver you could have 
validation
on your end device if you want.

So long
-Ralf
---
Ralf Weber

---

From: Willem Toorop <[email-masked]>
Date: Thu, 22 Aug 2019 14:07:55 +0200

> and I know that there are more European ISPs that are planning to turn

Yes, on RIPE Atlas 60% of the resolvers now does DNSSEC validation:

	https://dnsthought.nlnetlabs.nl/#rsasha256

And here is the graph showing the top ASNs of the IPs seen at the
authoritative for those DNSSEC validating resolvers:

	https://dnsthought.nlnetlabs.nl/can_rsasha256/#top_auth_asns

Yes, Google & Cloudflare count for 43.7% of validating resolvers, but
validation is increasing also without them.  One noteworthy party that
started DNSSEC validation recently is Deutsche Telekom, see:

	https://dnsthought.nlnetlabs.nl/auth_AS3320/#rsasha256

Consequently they also stopped NX domain hijacking :)

	https://dnsthought.nlnetlabs.nl/auth_AS3320/#top_nxhj_asns

Perhaps the threat of DoH (and the TRR) alone already stimulates the
ISPs to deliver better resolvers? ;)

-- Willem

---

From: Jim Reid <[email-masked]>
Date: Thu, 22 Aug 2019 13:41:07 +0100

> On 22 Aug 2019, at 08:00, Eric Rescorla <[email-masked]> wrote:
> 
> Suppose that I receive a bogus response to my A record query, how am I to usefully distinguish "this is malware blocking" from "this resolver is malicious"?

I'm surprised that distinction matters to you. I thought any form of DNS blocking or filtering was malicious from your PoV. :-)

To be slightly less glib, the dnsop WG has an I-D on extended error codes. [And FWIW lack of a discrete error code(s) for validation failure is one of the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error already goes some way to answering your question:

4.16.  Extended DNS Error Code 15 - Blocked

   The resolver attempted to perfom a DNS query but the domain is
   blacklisted due to a security policy implemented on the server being
   directly talked to.

4.17.  Extended DNS Error Code 16 - Censored

   The resolver attempted to perfom a DNS query but the domain was
   blacklisted by a security policy imposed upon the server being talked
   to.  Note that how the imposed policy is applied is irrelevant (in-
   band DNS somehow, court order, etc).

4.18.  Extended DNS Error Code 17 - Prohibited

   An authoritative or recursive resolver that receives a query from an
   "unauthorized" client can annotate its REFUSED message with this
   code.  Examples of "unauthorized" clients are recursive queries from
   IP addresses outside the network, blacklisted IP addresses, local
   policy, etc.

I suppose draft-ietf-dnsop-extended-error could add another error code for the specific case of a malicious resolver. Whatever that might mean. Though I doubt the operators of such servers will choose to set that evil bit on their responses.

PS A potential problem with this I-D is these extended error codes won’t be signed. So they can be spoofed by bad actors.

---

From: Rubens Kuhl <[email-masked]>
Date: Thu, 22 Aug 2019 13:50:38 -0300

While IETF usually focus on technical documents for implementers and operators, I believe that in this space an end-user document might be in order. Some sort of "Pick your enemy" document, where users can be educated on the different threat actors:
- Corporate network administrators
- ISPs
- Big web-scales
- Governments
- Rogue applications developers (malware etc.)
- Non-rogue application developers (browser developers)

Rubens

> Em 20 de ago de 2019, à(s) 17:01:000, Jari Arkko <[email-masked]> escreveu:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Aug 2019 09:47:25 -0400

You move the Answer section data to the Authoritative section, and add an extended error code that the answer was filtered by policy. This allows a dnssec validator to validate and censor if it is configured to do so.

This is my proposal for rpz-bis which is only waiting on the rpz draft to go through the ISE.

Paul

Sent from mobile device

> On Aug 22, 2019, at 03:00, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I certainly agree that from a cryptographic perspective, DNSSEC allows you to evaluate whether or not the records that you receive are those which were provisioned (modulo typos, key expiry, etc.). However, as has been observed here a number of times, there are many cases where the resolver desires to elide certain records (e.g., for malware filtering) or to redirect you to some other location (e.g., captive portals). So from a systems perspective it seems like things are more complicated. Suppose that I receive a bogus response to my A record query, how am I to usefully distinguish "this is malware blocking" from "this resolver is malicious"?
> 
> -Ekr
> 
>> 
>> 
>> -- 
>> Add mailing list
>> [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Aug 2019 09:53:30 -0400

> On Aug 22, 2019, at 06:26, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I agree that there is a risk, but given that we know that the current design *also* has a high risk of surveillance and other leaks, and that in fact those sorts of things regularly occur, this doesn't seem to me to be anywhere near as strong an argument as you seem to think it is. 

As a non-US citizen, I strongly disagree that the argument that we are putting all eggs in US baskets is not a strong argument. The US government formally gives me 0 expectation of privacy and they dictate policy to US entities. It is worse informally as we’ve seen time and time again (echelon, Snowden etc).

While I understand you might feel okay with your government’s policies to protect your privacy please remain aware that is a very privileged position to be in.

Paul

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Aug 2019 21:41:54 +0000

From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
Date: Wednesday, August 21, 2019 at 6:23 PM
To: David Conrad <[email-masked]>
Cc: Jim Reid <[email-masked]>, ADD Mailing list <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [Add] data integrity and DNSSEC or DoH/DoT

On Wed, Aug 21, 2019 at 3:15 PM David Conrad <[email-masked]<mailto:[email-masked]>> wrote:
My response to Ted that caused me to get sucked into this particular swamp (something I already regret)

> Is that the swamp where the only significant DNSSEC providers are Google and Cloudflare?

[JL] Please note that Comcast performs DNSSEC-validation in the US for our customers. ISPs in other countries do as well. So it’s not just the big quad platforms. That isn’t to say that DNSSEC deployment doesn’t still have a ways to go, but such is life. For reference, see https://corporate.comcast.com/comcast-voices/dnssec-deployment-update
and https://corporate.comcast.com/comcast-voices/comcast-completes-dnssec-deployment.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Aug 2019 22:44:26 +0000

will find this an attractive space to explore (I bet a beer we
    see a raft of publications in the next year or so:-). 

[JL] I chair a grants fund at work - the Comcast Innovation Fund - https://innovationfund.comcast.com/. If any academics reading this have interesting research proposals (or open source software development proposals) on this subject, you can post them at that URL. We just approved a few DoH-related things (not yet announced). So, I won't bet you that beer but I'd be more than happy to have a beer with you anyway! :-)

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Aug 2019 23:48:20 +0000

to turn it off. 

[JL] It might be useful, when your UX team is ready, to share what the user interaction flow will look like, how the choices are presented, and what the defaults are. This could lead the way for others and help establish best practices and transparency. Certainly there's been lots of discussions on 'dark patterns' in UX design (see https://gizmodo.com/senators-introduce-bill-to-stop-dark-patterns-huge-plat-1833929276), so I think end users are getting increasingly sensitized to how interface design choices can drive user selections/behavior. 

[JL] If the TRR program is successful then you'll be adding new TRRs all the time. As a result, it might also be useful to describe whether users will be prompted again/periodically in the future, such as when a new TRR was detected that is local to them (e.g. on-network via their ISP) and suggesting they may wish to switch to that one -- or what happens when a change in geography is detected (e.g. the user has moved from NYC to Tokyo).

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 23 Aug 2019 00:03:04 +0000

From: Add <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Subject: Re: [Add] What to do in this potential working group

>> On Tue, Aug 20, 2019 at 1:01 PM Jari Arkko <[email-masked]<mailto:[email-masked]>> wrote:

> I certainly agree that centralization is not ideal, but this recommendation needs to be balanced against other values, in this case, having the DNS queries go to a provider with determined, acceptable, privacy policies -- which, after all, is how we got here in the first place. So, no, I don't think that this proposed recommendation would be right as-is.

[JL] On this narrow point, I do think that one of the core concerns that I hear from many people stems from the risks, issues, and long-term effects of centralization. Interestingly in this case it appears to be centralization in combination with perceived, actual, or potential market share / power / control, which comes at a time socially and politically of increasing concerns over centralization its effects on societies.

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Aug 2019 19:23:12 -0500

> As a non-US citizen, I strongly disagree that the argument that we are putting all eggs in US baskets is not a strong argument. The US government formally gives me 0 expectation of privacy and they…

Are you talking about Canada?

https://qz.com/92648/think-us-snooping-is-bad-try-italy-india-or-canada/

https://citizenlab.ca/2019/08/canadas-new-and-irresponsible-encryption-policy-how-the-government-of-canadas-new-policy-threatens-charter-rights-cybersecurity-economic-growth-and-foreign-policy/

https://www.reuters.com/article/us-canada-spying/snowden-files-show-canada-spy-agency-runs-global-internet-watch-cbc-idUSKBN0L11W520150128

/a

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Aug 2019 05:32:01 +0100

> they can not join because it’s impossible to fulfil the other requirements

Interesting. I'd be interested in seeing links to those privacy policies.

> - No DNSSEC

I don't see how us not requiring DNSSEC precludes ISPs joining

> - Requirement to publish block lists

I think we've explained our reasons for these, and we're not yet persuaded
that relaxing them would be a good thing.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Aug 2019 05:39:13 +0100

On Thu, Aug 22, 2019 at 1:41 PM Jim Reid <[email-masked]> wrote:

> > Suppose that I receive a bogus response to my A record query, how am I
> to usefully distinguish "this is malware blocking" from "this resolver is
> malicious"?
>
> I'm surprised that distinction matters to you. I thought any form of DNS
> blocking or filtering was malicious from your PoV. :-)
>

Smiley or no, this really doesn't seem like it advances the conversation.

> To be slightly less glib, the dnsop WG has an I-D on extended error codes.
> [And FWIW lack of a discrete error code(s) for validation failure is one of
> the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error
> already goes some way to answering your question:
>
> I suppose draft-ietf-dnsop-extended-error could add another error code for
> the specific case of a malicious resolver. Whatever that might mean. Though
> I doubt the operators of such servers will choose to set that evil bit on
> their responses.
>
> PS A potential problem with this I-D is these extended error codes won’t
> be signed. So they can be spoofed by bad actors.

Yes, and for this reason I don't see how this solves the problem. It's just
"resolver blocked it and claims reason X".

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Thu, 22 Aug 2019 21:53:49 -0700

> Smiley or no, this really doesn't seem like it advances the conversation.

I agree with Ekr.

thanks,
Rob

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Aug 2019 09:04:16 +0100

On 23 Aug 2019, at 05:39, Eric Rescorla <[email-masked]> wrote:
> Yes, and for this reason I don't see how this solves the problem. It's just "resolver blocked it and claims reason X".

Which I thought answered your original question. Though maybe those responses should be signed somehow. Handwave, handwave. If you have suggestions on how to improve the security considerations of that I-D, please supply text to dnsop.

But now I’m confused. Could you please clarify what you mean by malicious resolver? We seem to be using different (unwritten) definitions.

I also don’t understand why it matters to distinguish between responses that say "this is malware blocking" from "this resolver is malicious”. The end result’s the same - the resolver’s not returning the expected DNS data for the query. What difference does it make if the resolver’s giving a genuine or a bogus reason for doing that? After all, the client will almost always believe what the resolver told them. It entered into an implicit or explicit trust relationship with that resolver when the client sent its DNS queries there.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 23 Aug 2019 13:55:52 +0200 (CEST)

> Il 23 agosto 2019 02:23 Adam Roach <[email-masked]> ha scritto:
>  
> > As a non-US citizen, I strongly disagree that the argument that we are putting all eggs in US baskets is not a strong argument. The US government formally gives me 0 expectation of privacy and they dictate policy to US entities. It is worse informally as we’ve seen time and time again (echelon, Snowden etc)
> 

I think that the IETF should not go down the road of making judgements about specific countries and their policies, but rather stick to the basic principle of sovereignty, which has kept the world together for the last few centuries: each country has the right to determine the rules for its own citizens, and each citizen has the right to live (and access the Internet) under their own country's rules and not under some other country's ones.

So it is a reasonable concern for non-US citizens to be worried about their data going to the US, independently from whether their own laws are better or worse than those of the US.

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Aug 2019 13:25:16 +0100

On Fri, Aug 23, 2019 at 9:04 AM Jim Reid <[email-masked]> wrote:

> >> > Suppose that I receive a bogus response to my A record query, how am
> I to usefully distinguish "this is malware blocking" from "this resolver is
> malicious"?
> >>
> >> I suppose draft-ietf-dnsop-extended-error could add another error code
> for the specific case of a malicious resolver. Whatever that might mean.
> Though I doubt the operators of such servers will choose to set that evil
> bit on their responses.
> >>
> >> PS A potential problem with this I-D is these extended error codes
> won’t be signed. So they can be spoofed by bad actors.
> >>
> > Yes, and for this reason I don't see how this solves the problem. It's
> just "resolver blocked it and claims reason X".
>
> Which I thought answered your original question. Though maybe those
> responses should be signed somehow. Handwave, handwave. If you have
> suggestions on how to improve the security considerations of that I-D,
> please supply text to dnsop.
>
> But now I’m confused. Could you please clarify what you mean by malicious
> resolver? We seem to be using different (unwritten) definitions.
>
> I also don’t understand why it matters to distinguish between responses
> that say "this is malware blocking" from "this resolver is malicious”. The
> end result’s the same - the resolver’s not returning the expected DNS data
> for the query. What difference does it make if the resolver’s giving a
> genuine or a bogus reason for doing that? After all, the client will almost
> always believe what the resolver told them. It entered into an implicit or
> explicit trust relationship with that resolver when the client sent its DNS
> queries there.

Let's go back to your original message, which made the distinction between
actual truth and whatever the resolver told you "DNSSEC validation means
you get the truth, the whole truth and nothing but the truth regardless of
your choice of resolver or the transport path between you and that
resolver. DoH and DoT offer no protection at all from a lying resolver -
you’re just guaranteed to receive precisely whatever lies or truth that
resolver sends" This distinction is only relevant if you actually aren't
going to just trust whatever the resolver tells you.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Fri, 23 Aug 2019 10:29:52 -0400

> On Aug 23, 2019, at 8:25 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> Let's go back to your original message, which made the distinction between actual truth and whatever the resolver told you "DNSSEC validation means you get the truth, the whole truth and nothing but the truth regardless of your choice of resolver or the transport path between you and that resolver. DoH and DoT offer no protection at  all from a lying resolver - you’re just guaranteed to receive precisely whatever lies or truth that resolver sends" This distinction is only relevant if you actually aren't going to just trust whatever the resolver tells you.

There are two kinds of “blocked” answers that a resolver doing this kind of blocking would return. All non-blocked answers would pass such a check. 

The two kinds are:
1) A non-zero response code (indicating an error) with Jim’s suggested extended error code explaining why. This “lie” is meta-data only. The only time this response would fail to validate is if it was an NXDOMAIN response, which would require a signed proof of non-existence. Adding Jim’s suggested logic only blocks access, it never requires trusting data in the answer. (Adding a signed proof might be possible but would require adding DNSSEC trust anchors.)
2) A substitute response, typically directing the client (user) to a “walled garden” explaining the blocking and possibly doing other things (like offering the user the option of reporting a false positive). There may be ways to sign these substitute responses, but those would require additional DNSSEC trust anchors (on the client).

If the blocking is done using only the first type of response, the distinction is significant: the client only ever has to trust negative answers marked as “blocked by XXX”. All other answers would validate. The client would never have to trust a bogus positive answer.

If additional trust anchors are used, their use could be restricted to answers marked with extended response codes, and highlighted by the browser as such. In this case, all responses would be validated, either with the standard trust anchor, or with an extra trust anchor used only for blocking.

Brian

---

From: Jim Reid <[email-masked]>
Date: Mon, 26 Aug 2019 16:37:04 +0100

> On 23 Aug 2019, at 13:25, Eric Rescorla <[email-masked]> wrote:
> 

Indeed. 

However I don’t understand how this relates to the point you seemed to be making, namely differentiation between a resolver that’s blocking malware and a malicious resolver (for some definition of that term). Could you please apply some clue?