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

[Ted Hardie <[e-mail]>]

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.

On Wed, Aug 21, 2019 at 3:55 AM Jari Arkko <[e-mail]> 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.
>
> - 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
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>