Subject: [Add] Ongoing discussion of DoH, DoT, and related issues

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Apr 2019 14:19:46 -0400

A mailing list has been created for the ongoing discussion of issues
with DNS over HTTPS, DNS over TLS, implementation choices for those,
application usage, operational concerns, privacy concerns, performance
concerns, and any other such.  Please take all that related discussion
to the new list and please stop discussing it on DOH, DPRIVE, DNSOP,
and any other lists — that will keep the related discussion in one
place, and avoid fragmenting it and having people repeat themselves
because of the fragmentation.

The new list is called ADD — Applications Doing DNS:
   https://www.ietf.org/mailman/listinfo/add
...and it's in the "to" list of this message.  Subscriptions are now open.

With this message I’m asking the working group chairs for DOH, DPRIVE,
and DNSOP to be strict about stopping discussion of these topics on
their lists, and directing people to the new “ADD” list.

Of course, work directly relevant to the charters of these working
groups should continue on their respective lists, as usual.

For the longer term, the relevant ADs are discussing the right path.
At the moment that looks like a BoF in Montreal (IETF 105) aimed at
forming an “ADD” working group, most likely in the ART Area but with
significant crossover expected and desired from Ops, Sec, Int, and
probably the rest of the <strike>solar system</strike> IETF community.

Barry Leiba, ART AD

---

From: Ray Bellis <[email-masked]>
Date: Wed, 10 Apr 2019 17:47:14 +0100

> probably the rest of the <strike>solar system</strike> IETF community.

With respect Barry, I hope this does *not* happen in the ART Area.

This whole mess started, IMHO, because some parties are treating the DNS 
as an application service, and not as part of the infrastructure and 
network services.

Traditionally, name resolution has always been a service that has been 
configured by the network, and via the operating system, and often (but 
not always) name resolution would use the DNS.

While individual applications are free to open connections to port 53 to 
perform DNS lookups, the vast majority do not, at least not within their 
own source code.

Sure, they call getaddrinfo() or perhaps even still gethostbyname() - 
i.e. system-provided library calls that do end up linked into the 
userspace application, but those still rely on nsswitch.conf and/or 
resolv.conf and can access all those other naming systems that are *not* 
DNS.   [UNIX specific stuff just given as examples.  YOSMV].

For DoH-as-a-service to get universal acceptance it needs (IMHO) to get 
plugged into those operating system level APIs as Google have done with 
DoT in Android Pie.  If I want to use DoH it has to be a single setting 
for the whole computer, and not set up separately in every application.

By all means have an O/S level UI where the user can manually override 
the network provided settings, in full knowledge that they may be in 
violation of the local network's security policies.

Having individual applications do that without the informed consent of 
their users is over-reach, IMHO, whatever their lawyers write into their 
shrink-wrap licenses.

regards,

Ray Bellis
ISC Research Fellow

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Apr 2019 21:50:19 +0100

Hi Ray,

> With respect Barry, I hope this does *not* happen in the ART Area.

FWIW, I'd be neutral about whichever area lands up with some
work so long as the right people stay involved and things are
appropriately scoped. But you do have a bit of a point too,
now that we better know how much this exercises folks mainly
involved in the ops/int areas, the IESG really need to organise
so that they stay engaged;-)

> as an application service, and not as part of the infrastructure and

I don't think that's accurate. My take is that DNS privacy work
started for perfectly valid privacy reasons and that DoT (while
a fine thing) wasn't the right tool for some who need that better
privacy... hence DoH. IMO it is a problem that an application
can't ask-that/tell-if the OS uses DoT (or DoH), and have that
work reliably enough on the various platforms on which typical
applications run. Applications have similarly preferred foo/TLS
to IPsec for some of the same reasons.

> not always) name resolution would use the DNS.

Right. But "tradition" isn't a good argument in itself:-)

> violation of the local network's security policies.

"May be in violation" seems to me a pretty partial way to look at
things. There are many networks where there's no "violation" at
all associated with any choice of recursive.

> their users is over-reach, IMHO, whatever their lawyers write into their

Partly agree. I hate the license-crap the s/w business involves so
agree with you there. OTOH, I disagree that informed consent is at
all feasible here - we simply cannot expect a typical user to spend
literally hours of work needed to really understand the issues here.
And without understanding there can be no informed consent, except
perhaps in some weasel-wordy manner. IOW, I think arguments about
consent here are about as convincing as asking that people look up
BGP information before allowing their packets be routed.

Cheers,
S.

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 10 Apr 2019 21:58:26 +0100

As we go up the networking layers in OSI from physical to application we 
go from most privileged components in a system from networking hardware, 
through to kernel drivers, the kernel, and finally into userland, and at 
layers 4/5 is usually the boundary between kernel and userland[0].

Putting a DoH client into kernel space changes that architecture quite 
significantly, and I am skeptical implementors like glibc for example 
would be up for this.

Regards

[0] Yes I am aware of userland Layer 3, or even userland network 
drivers. These too break this mold.

On 10/04/2019 17:47, Ray Bellis wrote:
> This whole mess started, IMHO, because some parties are treating the 
> DNS as an application service, and not as part of the infrastructure 
> and network services.
>
> configured by the network, and via the operating system, and often 
> (but not always) name resolution would use the DNS.
>
> While individual applications are free to open connections to port 53 
> to perform DNS lookups, the vast majority do not, at least not within 
> their own source code.
>
> resolv.conf and can access all those other naming systems that are 
> *not* DNS.   [UNIX specific stuff just given as examples.  YOSMV].
>
> For DoH-as-a-service to get universal acceptance it needs (IMHO) to 
> get plugged into those operating system level APIs as Google have done 
> with DoT in Android Pie.  If I want to use DoH it has to be a single 
> setting for the whole computer, and not set up separately in every 
> application.
>
> their users is over-reach, IMHO, whatever their lawyers write into 
> their shrink-wrap licenses.
>
> regards,
>
> Ray Bellis
> ISC Research Fellow
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 10 Apr 2019 22:01:50 +0100

> significantly, and I am skeptical implementors like glibc for example 

Nobody was talking about kernel space.

Technically, most UNIX do actually perform their naming lookups from 
userspace, but they do it with O/S provided APIs that honour the network 
provided name servers, unless manually configured otherwise.

Ray

---

From: Michael Sinatra <[email-masked]>
Date: Wed, 10 Apr 2019 15:29:37 -0700

On 2019-04-10 13:50, Stephen Farrell wrote:

> privacy... hence DoH.

I realize you realize that begs the following question... :-)

What's "better" about the privacy afforded by DoH?  If applications
choose which DNS server to use without the informed consent of the user
or in ways that obfuscate the DNS transaction and undermine the user's
control, that potentially _erodes_ privacy.  If DoH encourages network
administrators in certain regulatory (imagined or real) domains to do
inline TLS decryption, that potentially _erodes_ the user's privacy.

IMO, this mess started for two reasons:

First, DoH advocates internalized a particular definition of privacy and
made the assumption that DoH maximized privacy according to that
definition, within the constraints of a particular set of use-cases.
Based on the debate in these forums, it doesn't feel like DoH advocates
considered the full range of use-cases, and how different sets of users
define "privacy."

Second, applications developers like Mozilla made the assumption that
their vetting of DNS providers was sufficient to justify announcing
their intent to use said providers by default, rather than leaving that
decision as a user opt-in.  (And the announcement of intent was enough
to create this mess, even if they didn't or won't follow-through.)

It's perfectly reasonable to say that DoH improves certain aspects of
privacy under certain use-cases.  It's also reasonable to recognize, and
appropriately disclaim, that there are use-cases and circumstances where
DoH can undermine privacy.  This is why I believe we need to continue
work on draft-reid-doh-operator-00,
draft-livingood-doh-implementation-risks-issues-03, and
draft-bertola-bcp-doh-clients-00.

> literally hours of work needed to really understand the issues here.

I think your definition of "typical user" is unduly narrow.  Regardless,
DoH doesn't absolve the user from understanding the issues at hand.  It
simply migrates the management of a component of the user's personal
information from "network" to "application," potentially without
informing the user or letting them opt-in.  IMO the IETF can and should
take a stand that this is not the desired BCP for DoH.

> BGP information before allowing their packets be routed.

I think your analogy is wide of the mark.  The correct analogy would be
having users select network providers on the basis of their privacy
policies and their routing hygiene (prefix filtering, MANRS-compliance,
origin-validation practices, etc.).  You might say, "but not all users
do that!" and you would certainly be right.  But some do take those
factors into consideration (or they ask knowledgeable folks to make
informed recommendations) and they should be given the necessary
information to make an informed decision.  And the IETF *can* influence
this through BCPs.

michael

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Apr 2019 23:55:49 +0100

Hiya,

On 10/04/2019 23:29, Michael Sinatra wrote:
> What's "better" about the privacy afforded by DoH? 

Eh.. that was in the paragraph from which you quoted above... in
the bit you didn't quote;-)

Basically, if the application wants to know that DNS privacy
is being applied, it has to do it itself. (There are other
arguments, and I'm not a browser-maker so they may have other
reasons they think more important.)

> If applications

I've already disputed the possibility of informed consent here.
(And will do again below:-)

> inline TLS decryption, that potentially _erodes_ the user's privacy.

Yes, if people bugger about MitM'ing TLS, that harms us all.

Every time we see an interesting uptick in use of TLS in any
sphere, we see claims that we'll be overwhelmed by MitMs to
defeat that and arguments that the putative potential fault
for that lies with whomever is causing the uptick. The fact
that that keeps happening seems to be evidence that uses of
TLS between intended endpoints are not being overwhelmed in
that way. That's a good thing IMO even if there are a few
more MitM attack boxes deployed than previously when pretty
much everything was in clear and utterly vulnerable.

In the current discussion, if you do control the client endpoint,
then manage that well and you'll have no need to bugger with TLS
at all. If you do not control the endpoint (or are inept in
doing so) then I'd be interested in how you propose to go about
MitM'ing TLS.

> First, DoH advocates internalized 

Your or my guesses as to who internalised what seem unlikely to
be a useful part of the discussion. (You'll note I framed my
explanation in terms of what's visible-to/controllable-by different
bits of s/w running on a machine, and not in terms of people's
motivations, which I think ought not be a topic for discussion
here.)

> a particular definition of privacy and
> I think your analogy is wide of the mark. 

My argument was not an analogy.

To re-iterate:

"without understanding there can be no informed consent"

is the core of my argument on this part of the discussion. I'm
quite happy to defend that proposition (which is not an analogy).

Cheers,
S

> The correct analogy would be

---

From: Michael Sinatra <[email-masked]>
Date: Wed, 10 Apr 2019 16:51:38 -0700

> the bit you didn't quote;-)

Oh, I am sorry about that...(seriously)

> reasons they think more important.)

Okay, what I am about to say is going to sound sarcastic but it's not.
The reason I didn't quote that text is it seemed like you were
discussing application signaling and that seemed so distant from my
definition of privacy that it didn't appear to be relevant.  If you are
saying that privacy == application knowledge of whether encrypted
transport is being used, then that supports my point that DoH
presupposes a particular definition of privacy and I would agree that
DoH does improve privacy according to that definition.  But there are
other definitions.  For example, a reasonable person may define privacy
(or one aspect of it) as the number of external entities that have
access to personal information.  If an application uses DoH to choose
some third party (say Cloudflare) to do DNS resolution instead of my
local on-network DNS recursive server, then Cloudflare has access to my
DNS queries, where, in the past they didn't.  My ISP and application
providers continue to have access to connection (netflow) data and
HTTP(S) requests, which they did in the past.

> doing so) then I'd be interested in how you propose to go about

Totally agree, and that's one of the reasons I am a big supporter of TLS
1.3, in whose favor the same arguments were made.  But I am uneasy about
giving ammo to the other side.

> motivations, which I think ought not be a topic for discussion

Totally disagree.  If we can't be explicit about the motivations that
drive efforts like DPRIVE and DoH, then we can't attempt to align those
motivations with those of users (broadly defined), and we will continue
to create solutions that are counter to how our users view privacy.

> My argument was not an analogy.

You specifically stated that arguments in favor of informed consent
can't be convincing and you gave an unsatisfactory analogy in support of
that statement.

> is the core of my argument on this part of the discussion. 
The proposition is not an analogy, but the evidence you submitted in its
support was.  (Actually, the evidence you submitted was an analogy that
attempted to contradict counter-arguments to your point, but whatever.
I am not keeping score.)

> I'm

Save it.  I am not interested in having the IETF take the position that
it's impossible for users to make informed technology choices and that
therefore, said users should not be empowered to do so, and that
instead, application developers should wield such power.

michael

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Apr 2019 01:37:31 +0100

Hiya,

> Oh, I am sorry about that...(seriously)

No probs.

> transport is being used, 

No, "==" isn't correct. But "requires" gets close. IOW,
an application (developer) can't really deal effectively
with whatever good definition of DNS privacy they use,
if there's a blood-brain barrier like sending cleartext
to localhost:53 or calling getaddrinfo() on all of the
platforms on which that application gets deployed.

I would hope such an application developer would also
then do qname minimisation, not send client-subnet (unless
needed) etc, so just using TLS is not at all the definition
of DNS privacy (for me at least). And I would also hope
that that same application developer cares about more than
just DNS privacy. As it happens, I think browsers do not
do a good job on privacy as they've been far too fanatical
about performance and market-share over the last decade+,
but that doesn't mean that their efforts at DNS privacy
are fake or worthless.

> then that supports my point that DoH
> access to personal information. 

Sure. I agree. And also that the concentration of lots (and lots
and lots) of people's personal information in any one entity is
pretty crap. And worse than crap when there are effectively only
O(1) such entities on the Internet.

There is however a technical challenge - privacy does require
some hiding in the crowd, which seems call for centralising
things some. Maybe we've yet to learn how to do that better or
how to setup the right number of crowds in which to hide.

> If an application uses DoH to choose

That argument ("the n/w provider still gets the stuff") seems to
conflict with a bunch of other arguments from folks who claim to
be unhappy with FF/CF's DoH-plans. (FWIW, I do think that, should
arrangements like the FF/CF deal become common, then n/w operators
would have access to less data. I also think that's ok.)

> to create solutions that are counter to how our users view privacy.

Well, I can be explicit about my motivations. It'd be wrong
for me to describe yours though. If we disagree about that,
that's not the end of the world ('cause I already know what
you're thinking:-). My experience though is that ascribing
motives to other people in contentious email discussions tends
to turn out somewhere between badly and really awful.

> can't be convincing and you gave an unsatisfactory analogy in support of

Ah, fair enough. (Except of course that it was an excellent
analogy to support my proposition:-)

> instead, application developers should wield such power.

But that's not my argument. Informed consent is entirely possible,
but the probability of it happening is miniscule. There is therefore
no point in pretending that informed consent could ever be depended
upon in this case.

ISTM therefore that everyone calling for so-called consent (whether
that be a ISP unhappy about the Moz/CF stuff, or a web-site and/or
browser supposedly asking about cookies), *and* everyone saying
that they already have so-called consent and therefore don't need
to ask, (for whatever definition of those words have kept their
lawyers happy) seems to be espousing a position that's somewhere
between highly-mistaken and a bunch of self-serving lies.

Cheers,
S.

---

From: George Michaelson <[email-masked]>
Date: Thu, 11 Apr 2019 10:53:44 +1000

it's probably naieve of me, but I did mentally segment my thoughts
abouy DoH (and DoT and DoC and ...) into two parts.

1) the characterization of on-the-wire or in-protocol encoding and
structural forms

2) the other stuff, including whats baked into a browser and whats
under user control.

I feel 1) is easier, but also crucial because without it, we face
developers writing their own lightweight JS to encode a HOSTS.TXT
model of reference by name to IP addressed objects. I am led to
believe this is going to happen anyway and maybe this is a moment
which has passed (or passes to other hands) because its unstoppable.

2) is where the meat in the sandwich is. I had not understood the
distinct tensions (tussles?) here between regulatory oversight,
centralization and actual user desire. I dislike the aspect of this
problem that presents as an operators "not on my network" view but I
now understand it has distinct flavours: People who have obligations
in law, need to understand how technology affects their obligations in
law.

I would be very upset if DoH emerged as a system I cannot (as the user
behind the keyboard) control. If it emerges as a "never you mind about
that" technology, I'd be very upset and I think a lot of users would
be very upset. I don't see a reason to mis-characterize actors (CF) in
this, so a single entity standing up a service which people CAN code
to, is quite different to things being baked into code in a browser.
I should stress i doubt very much any browser doing DoH would or could
bake it in, without exposing user controls.

I would like to continue to think we're realistic about our limits to
affect the system overall. It would surprise me if Microsoft (for
instance) did not intend coding things stand-alone, or Google, or
Firefox, or Opera. I don't sense the people who might code to this are
yet converged into a standards-baking room. Maybe I am wrong there
too?

PS if anyone feels objectified by how I "spoke" in prior mails or at a
microphone, I apologize un-reservedly.

-G

---

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

Moin!

> reasons they think more important.)
There is nothing in DoT that prevents you from doing that, so
it’s clearly not the reason why DoH was done. As others said
if the goal was to hide in normal traffic that is exactly what
malware does, and this is what created a big problem for a lot
of people trying to stop malware.

So long
-Ralf
—--
Ralf Weber

---

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

>     Il 11 aprile 2019 alle 2.37 Stephen Farrell < [email-masked] mailto:[email-masked] > ha scritto:
> 
While I agree that explaining things to the user might not be easy, the basic principle of GDPR-style privacy laws is that consent is required unless you fall into some specific exceptions, and I've never seen "this is too hard to explain" mentioned as a valid exception. In other words, the principle is "if you can't explain it and get proper consent, don't do it".

So if you continued along this line of thought, the consequence would be that any DNS resolution activity on behalf of human beings is illegal, or, if you want to be a little more liberal, that any change of the user's DNS settings from the default is illegal, because users can't understand what they are doing and so cannot provide informed consent to such a specific change.

In reality, it is pretty common for the user to ask for services that they don't fully understand in technical terms. The way this works is that the user asks for a service (for example, Internet access) and then gives general consent to any data processing activity that is necessary to provide that service (for example, DNS resolution), even if the user doesn't understand or even know such activities. Applications willing to turn on DoH could possibly use the same mechanism, offering "private DNS" or even "private browsing" as the service, but they would still be required to inform the user on which information will be acquired, who is going to process it and for which purposes, providing separate opt-ins for each purpose.

(By the way - if the actual point you are trying to make is that any DNS operator, including ISPs, should be providing better information to users and make sure to really get meaningful consent, I'm all with you. But not if your point is that since consent is hard we'd rather disempower the user.)

Ciao,

--

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Apr 2019 12:06:28 +0100

> layers 4/5 is usually the boundary between kernel and userland[0].

There is a lot low-layer code in userland: DHCP, routing protocols,
diagnostic tools, many transport protocols, ...

And in the other direction, in-kernel implementations of application
protocols are not unheard of, especially if they are network file systms,
but also HTTP, TLS, telnet (back in the day when timesharing was big) ...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Great Orme Head to the Mull of Galloway: Variable 3 or 4, occasionally 2
overnight, becoming southeast 4 or 5 later. Smooth or slight. Fair. Good.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Apr 2019 14:01:31 +0100

Hiya,

On 11/04/2019 09:53, Ralf Weber wrote:
> There is nothing in DoT that prevents you from doing that, 

True. Applications could build-in DoT as well as or
instead of DoH. (Same for Do53 too.)

> so
> it’s clearly not the reason why DoH was done. 

There was a good bit of discussion of that that I forget
TBH;-) Encapsulating in HTTP was attractive for some JS
reason I never really got. And port 443 is more likely
unblocked I guess compared to 853. But a browser maker
would have to say why they prefer DoH to DoT I reckon.

> As others said
> malware does, and this is what created a biig problem for a lot

Yes, people writing both malware and anti-censorship
tools want to look like more normal traffic. But I'm
not sure that DoH vs. DoT to an "outside" recursive
are any different here given there are DoT servers
that listen on 443 too. (I use that myself with
stubby as some networks I use allow outbound 853
whilst others don't, so for me that's a mobility
issue and not related to censorship nor any attempt
to spread malware:-) But it seems in any case brittle
to assume that DNS traffic from malware will continue
to be easily visible.

I wonder is it the case that we'd have to see a widely
deployed application that uses DoH with unpredictable
web sites as DNS recursive before it being hard to
identify this traffic really comes into play? If so,
that doesn't sound like what mozilla have said they're
planning. (Mind you, I'm not sure how a browser would
handle a 3xx re-direct in response to a DoH query, so
it might not be terribly simple.)

Maybe this suggests there's scope to document ways
in which user-chosen, application-chosen, OS-chosen,
and n/w-chosen DNS recursives can be handled with DoH,
DoT and Do53, without having to adopt a hard position
that one way is right and all others are wrong? (That
said, I'm not sure if that'd be very useful or not,
and in any case, it's likely premature until someone
figures out how to handle split-horizon and maybe
local discovery.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Apr 2019 14:24:29 +0100

Hiya,

On 11/04/2019 10:17, Vittorio Bertola wrote:
> 
>> Il 11 aprile 2019 alle 2.37 Stephen Farrell <
>> [email-masked] mailto:[email-masked] > ha
>> scritto:
>> 
>> but the probability of it happening is miniscule. There is
>> therefore no point in pretending that informed consent could ever
>> be depended upon in this case.
>> 
> While I agree that explaining things to the user might not be easy,
> the basic principle of GDPR-style privacy laws is that consent is
> required unless you fall into some specific exceptions, and I've
> never seen "this is too hard to explain" mentioned as a valid
> exception. In other words, the principle is "if you can't explain it
> and get proper consent, don't do it".

I don't claim to understand GPDR, nor am I a lawyer. I do
claim that so-called consent as used by web applications
(and s/w in general) is almost always bogus. I'd further
argue that IETF RFCs ought never mention the term because
of that ubiquitous bogosity.

> So if you continued along this line of thought, the consequence would
> be that any DNS resolution activity on behalf of human beings is
> illegal, or, if you want to be a little more liberal, that any change
> of the user's DNS settings from the default is illegal, because users
> can't understand what they are doing and so cannot provide informed
> consent to such a specific change.
> 
> In reality, it is pretty common for the user to ask for services that
> they don't fully understand in technical terms. The way this works is
> that the user asks for a service (for example, Internet access) and
> then gives general consent to any data processing activity that is
> necessary to provide that service (for example, DNS resolution), even
> if the user doesn't understand or even know such activities.
> Applications willing to turn on DoH could possibly use the same
> mechanism, offering "private DNS" or even "private browsing" as the
> service, but they would still be required to inform the user on which
> information will be acquired, who is going to process it and for
> which purposes, providing separate opt-ins for each purpose.
> 
> (By the way - if the actual point you are trying to make is that any
> DNS operator, including ISPs, should be providing better information
> to users and make sure to really get meaningful consent, I'm all with
> you. But not if your point is that since consent is hard we'd rather
> disempower the user.)

I would welcome more transparency on what service providers
do with user-data and derived meta-data and would never want
to disempower users. But again, and no matter what a lawyer
might say, I don't consider it the case that just because
someone uses an ISP, means that they have given real consent
to everything the ISP does, or says it does in a contract.
I do accept that people who offer services have to operate
as if there were real consent involved, but there is not, IMO.

(That said, having DPAs force service providers to do better
because of GDPR is mostly positive, but it's not a panacea.
And I fully expect commercial entities to do as much as they
are forced to do by laws like GDPR, but no more, and that's
understandable.)

So for this discussion, I don't think arguments about so-called
consent are useful, as they bring in all the above issues, and
those are issues that can't be resolved via IETF discussion.

Cheers,
S.

> [email-masked]
> mailto:[email-masked] Office @ Via Treviso 12,
> 10144 Torino, Italy
>

---

From: Ray Bellis <[email-masked]>
Date: Thu, 11 Apr 2019 14:48:55 +0100

> instead of DoH. (Same for Do53 too.)

It would be better (IMHO) if operating systems did it.

I don't buy the arguments that browsers "need to know" whether a DNS 
connection is "private" or not.   Users may want to know that, sure, but 
that can be achieved just as well via the O/S resolver system.

I note that the WG charter does explicitly refer to "e.g. operating 
system stub resolvers" as consumers of the WG's deliverable.  That would 
be far more preferable (again, IMHO) than having applications each 
implement their own stub resolver logic.

> reason I never really got.

There's no standard W3C / ECMAScript API for making DNS lookups within a 
browser.

With DoH specified as carried inside HTTP you don't need an API at the 
level of a JavaScript function API at all, because DoH is then just 
something else that you can drop inside a REST call that would work in 
any current mainstream browser.

Ray

---

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

Moin!

> figures out how to handle split-horizon and maybe
Provisioning and defining how the different layers
interact with each other certainly is something we
should work on. Ideally we would have a standardised
API in the OS that would give applications access to
the secure transport they wanted, but that is a long
shot from where we are now and I’ve been told that
the IETF doesn’t standardise APIs.

So long
-Ralf
—--
Ralf Weber

---

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

> the IETF doesn’t standardise APIs.

The APIs already exist, e.g. libresolv, and the higher level calls that 
rely on them (e.g. getaddrinfo, etc).

They just need their _implementations_ to be updated to support DoX.

Ray

---

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

Moin!

On 11 Apr 2019, at 16:18, Ray Bellis wrote:

> The APIs already exist, e.g. libresolv, and the higher level calls 
> that rely on them (e.g. getaddrinfo, etc).
Well an API exists, but my understanding was that applications wanted to 
have more control over the resolution process, for which I think we need 
a new API.

> They just need their _implementations_ to be updated to support DoX.
Which would be good. Do you volunteer ;-)?

So long
-Ralf
—--
Ralf Weber

---

From: Ray Bellis <[email-masked]>
Date: Thu, 11 Apr 2019 15:38:37 +0100

On 11/04/2019 15:31, Ralf Weber wrote:

> have more control over the resolution process

Why?

In which consensus document are those requirements stated, and how would 
they not be met by having the system libraries directly handle the 
privacy and/or encryption of the DNS requests?

Ray

---

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

On 4/11/19 9:38 AM, Ray Bellis wrote:
>> Well an API exists, but my understanding was that applications wanted 
>> to have more control over the resolution process
>
> Why?
>
> In which consensus document are those requirements stated

That's not really the way the word "wanted" works.

I mean, we could produce a consensus document that defines Ray Bellis's 
favorite pizza toppings, but as long as someone other than you writes 
it, it's probably not going to bear on the ground truth of what your 
favorite pizza toppings actually are.

/a

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Apr 2019 15:55:32 +0000

> They just need their _implementations_ to be updated to support DoX.

Browsers update *much* faster than platforms, and I doubt any browser -- in particular one small one that treats "user privacy" as a selling point -- will wait.  It would be nice if they implemented on top of the common Linux getXXXX interface, and extended that as needed.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 11 Apr 2019 16:57:45 +0100

On 11/04/2019 16:55, Salz, Rich wrote:

> Browsers update *much* faster than platforms, and I doubt any browser
> -- in particular one small one that treats "user privacy" as a
> selling point -- will wait.  It would be nice if they implemented on
> top of the common Linux getXXXX interface, and extended that as
> needed.

Or they could put their considerable engineering resource into updating
the O/S code at the same time so that eventually *every* application can
benefit from it...

Ray

---

From: Brian Dickson <[email-masked]>
Date: Thu, 11 Apr 2019 09:03:04 -0700

> That's not really the way the word "wanted" works.

I think the question is not "what" you want (which toppings in your
analogy), but "why".

Specifically, if the application(s) want more privacy (and more security,
or at least no less security), why do they want/need to actually control
that?
Consider a slight difference, where the application doesn't control the
resolution process, but is able to verify what that resolution is.

And that is why the question/issue I've raised, and that Ray mentions
above, is "requirements".

The whole purpose of requirements is that that is a necessary element of
standardizing things, so you know what the goals are before designing and
coding things.

So, let me ask again:

What requirements (consensus or otherwise) are there, which are driving
these changes to DNS resolution (in the larger context)?

Brian