Subject: Re: [Doh] DoH

From: Patrick McManus <[email-masked]>
Date: Thu, 28 Mar 2019 16:55:50 +0100

Hi John - I cannot speak for the IETF, nor am I in a position to
effectively summarize all of the inputs over the year long process in
building RFC 8484. However the consensus opinion of that work is reflected
in that document. I can also refer you to the datatracker page for the
working group which includes the mailing list archives and minutes from in
person meetings while doing the work.
https://datatracker.ietf.org/group/doh/about/ The final consensus document
does contain some related content in section 10.

Best Regards,
-Patrick

On Thu, Mar 28, 2019 at 3:54 PM John Carr <[email-masked]> wrote:

> Hi Both,
>
>
>
> I refer to the IETF project on DNS queries over HTTPS (DoH)
>
>
>
> Could you tell me if, in the course of the deliberations which have been
> taking place within the IETF structures in respect of DoH, any
> consideration was given, or is being given, to the implications of this
> standard in terms of its likely impact on filtering solutions which have
> been implemented either  on routers within individual households, or by
> ISPs or other access providers, where the purpose of the filtering is
> either to restrict access to known illegal content or it is to restrict
> access to content which is considered inappropriate, e.g. for younger
> family members?
>
>
>
> Many thanks,
>
>
>
> John  Carr
>
> Secretary
>
> Children’s Charities’ Coalition on Internet Safety
>
>
>
> www.chis.org.uk
>
>
>

---

From: John Carr <[email-masked]>
Date: Thu, 28 Mar 2019 16:20:07 +0000

Many thanks. I represent children’s organizations which do not have  the resources to track the complexities or ins and outs of some of these sorts of issues.

Perhaps there is someone on the list who knows the answer to my question? Or are you saying I must wade through the whole shooting match and work it for myself?

John

From: Patrick McManus <[email-masked]>
Sent: 28 March 2019 15:56
To: John Carr <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: DoH

Hi John - I cannot speak for the IETF, nor am I in a position to effectively summarize all of the inputs over the year long process in building RFC 8484. However the consensus opinion of that work is reflected in that document. I can also refer you to the datatracker page for the working group which includes the mailing list archives and minutes from in person meetings while doing the work. https://datatracker.ietf.org/group/doh/about/ The final consensus document does contain some related content in section 10.

Best Regards,
-Patrick

On Thu, Mar 28, 2019 at 3:54 PM John Carr <[email-masked]<mailto:[email-masked]>> wrote:
Hi Both,

Could you tell me if, in the course of the deliberations which have been taking place within the IETF structures in respect of DoH, any consideration was given, or is being given, to the implications of this standard in terms of its likely impact on filtering solutions which have been implemented either  on routers within individual households, or by ISPs or other access providers, where the purpose of the filtering is either to restrict access to known illegal content or it is to restrict access to content which is considered inappropriate, e.g. for younger family members?

Many thanks,

John  Carr
Secretary

www.chis.org.uk<http://www.chis.org.uk>

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Mar 2019 18:08:21 +0100

[speaking as an individual contributor]

John --

The issue you're raising is not inherent to the DoH protocol. Since the 
advent of public DNS servers, which started to gain significant 
popularity with Google's service offering a decade ago [1], the various 
DNS-based approaches of content restriction that you describe in your 
original message have been fairly easily circumventable (e.g. by 
changing the DNS settings on a local machine, using TOR browser, or by 
using a VPN).

There has been significant discussion within the IETF, especially over 
the past few weeks, of some of the operational changes that result from 
the difference between DoH and other means of accessing DNS. These 
changes do have some bearing on sophisticated network operators, such as 
those who administer enterprise networks. For the types of home networks 
you mention, which generally lack professional and dedicated network 
administrators, DoH does not inherently represent any significant change 
to the decade-old status quo resulting from publicly-available DNS.

There has also been some speculation about, and announcements of, future 
behaviors that some applications -- notably, web browsers -- may choose 
to exhibit. While the development of the DoH protocol might have focused 
and potentially accelerated the decisions made by the vendors of those 
applications, it should be noted that the behaviors enabled by DoH are 
possible without any standardized protocol, and that browser vendors in 
particular were almost certainly going to deploy equivalent technology 
regardless of whether such standardization took place. As the IETF 
itself only has that information that has been sent to the DoH mailing 
list, it seems unlikely that you could get any useful answers to the 
questions you raise except for by contacting the vendors of such 
applications through their official public comms channels.

/a

____
[1] https://en.wikipedia.org/wiki/Google_Public_DNS

On 3/28/19 17:20, John Carr wrote:
>
> Many thanks. I represent children’s organizations which do not have  
> the resources to track the complexities or ins and outs of some of 
> these sorts of issues.
>
> Perhaps there is someone on the list who knows the answer to my 
> question? Or are you saying I must wade through the whole shooting 
> match and work it for myself?
>
> John
>
> *From:*Patrick McManus <[email-masked]>
> *Sent:* 28 March 2019 15:56
> *To:* John Carr <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: DoH
>
> building RFC 8484. However the consensus opinion of that work is 
> reflected in that document. I can also refer you to the datatracker 
> page for the working group which includes the mailing list archives 
> and minutes from in person meetings while doing the work. 
> https://datatracker.ietf.org/group/doh/about/ The final consensus 
> document does contain some related content in section 10.
>
> Best Regards,
>
> -Patrick
>
>     Could you tell me if, in the course of the deliberations which
>     have been taking place within the IETF structures in respect of
>     DoH, any consideration was given, or is being given, to the
>     implications of this standard in terms of its likely impact on
>     filtering solutions which have been implemented either  on routers
>     within individual households, or by ISPs or other access
>     providers, where the purpose of the filtering is either to
>     restrict access to known illegal content or it is to restrict
>     access to content which is considered inappropriate, e.g. for
>     younger family members?
>
>     Many thanks,
>
>     John  Carr
>
>     Secretary
>
>     www.chis.org.uk <http://www.chis.org.uk>
>
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 17:35:59 +0000

Ø  For the types of home networks you mention, which generally lack professional and dedicated network administrators, DoH does not inherently represent any significant change to the decade-old status quo resulting from publicly-available DNS.

I disagree, there is a fundamental change here.  If / when browsers enable DoH by default, it suddenly means that very large numbers of users will bypass filtering, whether in the home or other environments, possibly without even knowing that is the case.  This potentially exposes vulnerable groups such as children to harm, and may also contravene local or regional legislation – an issue for the browser companies and DoH resolvers.  These points were touched on in the DoH discusions this week.

The reasons this is different to the status quo with publicly-available DNS are: a) the volume of users involved; b) it is being implemented without the user seeking it out; and c) it is potentially being imposed without their consent.

No doubt the debate will continue!

Andrew

From: Adam Roach [mailto:[email-masked]]
Sent: 28 March 2019 17:08
To: John Carr <[email-masked]>; Patrick McManus <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Doh] DoH

John --

The issue you're raising is not inherent to the DoH protocol. Since the advent of public DNS servers, which started to gain significant popularity with Google's service offering a decade ago [1], the various DNS-based approaches of content restriction that you describe in your original message have been fairly easily circumventable (e.g. by changing the DNS settings on a local machine, using TOR browser, or by using a VPN).

There has been significant discussion within the IETF, especially over the past few weeks, of some of the operational changes that result from the difference between DoH and other means of accessing DNS. These changes do have some bearing on sophisticated network operators, such as those who administer enterprise networks. For the types of home networks you mention, which generally lack professional and dedicated network administrators, DoH does not inherently represent any significant change to the decade-old status quo resulting from publicly-available DNS.

There has also been some speculation about, and announcements of, future behaviors that some applications -- notably, web browsers -- may choose to exhibit. While the development of the DoH protocol might have focused and potentially accelerated the decisions made by the vendors of those applications, it should be noted that the behaviors enabled by DoH are possible without any standardized protocol, and that browser vendors in particular were almost certainly going to deploy equivalent technology regardless of whether such standardization took place. As the IETF itself only has that information that has been sent to the DoH mailing list, it seems unlikely that you could get any useful answers to the questions you raise except for by contacting the vendors of such applications through their official public comms channels.

/a

____

John

From: Patrick McManus <[email-masked]><mailto:[email-masked]>
Sent: 28 March 2019 15:56
To: John Carr <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: DoH

Best Regards,
-Patrick

Many thanks,

John  Carr
Secretary

Doh mailing list

[email-masked]<mailto:[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Mar 2019 19:11:14 +0100

On 3/28/19 18:35, [email-masked] wrote:
>
> ØFor the types of home networks you mention, which generally lack 
> professional and dedicated network administrators, DoH does not 
> inherently represent any significant change to the decade-old status 
> quo resulting from publicly-available DNS.
>
> I disagree, there is a fundamental change here.  If / when browsers 
> enable DoH by default...
>

Yes, and this pertains to product decisions rather than the DoH protocol 
itself. I tried to make this point in the third paragraph of my 
response. I apologize if that point was insufficiently clear.

/a

---

From: "Winfield, Alister" <[email-masked]>
Date: Thu, 28 Mar 2019 21:40:59 +0000

Top posting on purpose ….

I’ve tried to respond twice to this and I think third time I might get closer to my thinking…

The DoH solution (note not necessarily protocol) is missing at least two key elements which together would have reduced the immediate panic in the implementation. Not to say there aren’t other things that need work just the really problematic issues could be contained or deferred.

The current active work on discovery and somehow defining a trust and privacy mechanism surrounding TRR’s.

With trusted lists of TRR’s you’d then be able to use the output of a fundamentally insecure discovery method. If that ‘trust and privacy’ were to be selectable say by choice of provider. You get the option to allow the local network policy / or not. You can chose to allow trusted coffee shops but others may be not in your list because they do things that ‘you’ don’t like. Parents can chose to trust only those DNS providers that give strong parental controls. Whatever group you are in many things would be less controversial. Oh, it’s not easy but at least we wouldn’t be in the current position where it is almost certain that a sudden change will occur to a keystone of the Internet.

Worst case example is that given the billions of queries per second we are talking about here and the localisation of content delivery it impacts, many terrabytes per second of traffic could / would rapidly migrate to less-optimal CDN’s. The distribution of this might well break networks, sadly there is no research that can reliably work out the full impact. Small trials really don’t help because we already handle small percentages of non-local DNS use. It’s the unknown of what happens if 80% of the users in a single software update change to a non-local DNS provider (especially if it’s one that doesn’t forward granular enough EDNS client-subnet data because ‘privacy’).

I admit that last paragraph may be FUD, but in this case the risk to the stability of the Internet is potentially at stake so largest possible ‘we’ owe everyone a little time exposing the potential issues in detail with any mitigations if they exist. Preparing those who will be impacted for change and then somehow containing the initial  change so if it really does cause hard to contain issues we have a small enough problem its solvable in reasonable timeframes. Anyone who has done operations will tell you that big changes that happen fast are the nightmare you fight hardest to avoid.

One more thing I’ll repeat others warning.. beware unintended consequences this must not end in a fight between networks, or governments and DoH providers. If this goes wrong and corporates and other players decide this is a step too far because of the impacts we all know the outcome could be very messy and I for one would rather work to get a less painful and most likely less privacy impactful result.

NB: Don’t bite I do like the protocol and I agree that there are some that need it to exist.

--
Alister Winfield

From: Doh <[email-masked]> on behalf of Adam Roach <[email-masked]>
Date: Thursday, 28 March 2019 at 19:12
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Doh] DoH

On 3/28/19 18:35, [email-masked]<mailto:[email-masked]> wrote:

  *   For the types of home networks you mention, which generally lack professional and dedicated network administrators, DoH does not inherently represent any significant change to the decade-old status quo resulting from publicly-available DNS.

I disagree, there is a fundamental change here.  If / when browsers enable DoH by default...

Yes, and this pertains to product decisions rather than the DoH protocol itself. I tried to make this point in the third paragraph of my response. I apologize if that point was insufficiently clear.
/a
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Mar 2019 23:11:44 +0100

> On Mar 28, 2019, at 22:40, Winfield, Alister <Alister.Winfield=[email-masked]> wrote:
> 

Not going to bite, but I’ll point out that your response is largely unrelated to the query that started this thread. Perhaps you meant to reply to a different message?

/a

---

From: <[email-masked]>
Date: Fri, 29 Mar 2019 10:58:01 +0000

> The DoH solution (note not necessarily protocol) is missing at least two key elements which together would have reduced the 
> immediate panic in the implementation. Not to say there aren’t other things that need work just the really problematic issues 
> could be contained or deferred.

> With trusted lists of TRR’s you’d then be able to use the output of a fundamentally insecure discovery method. If that 
> ‘trust and privacy’ were to be selectable say by choice of provider. You get the option to allow the local network policy / or 
> not. You can chose to allow trusted coffee shops but others may be not in your list because they do things that ‘you’ don’t 
> like. Parents can chose to trust only those DNS providers that give strong parental controls. Whatever group you are in 
> many things would be less controversial. Oh, it’s not easy but at least we wouldn’t be in the current position where it is 
> almost certain that a sudden change will occur to a keystone of the Internet. 

> Worst case example is that given the billions of queries per second we are talking about here and the localisation of 
> content delivery it impacts, many terrabytes per second of traffic could / would rapidly migrate to less-optimal CDN’s. The 
> distribution of this might well break networks, sadly there is no research that can reliably work out the full impact. Small 
> trials really don’t help because we already handle small percentages of non-local DNS use. It’s the unknown of what 
> happens if 80% of the users in a single software update change to a non-local DNS provider (especially if it’s one that 
> doesn’t forward granular enough EDNS client-subnet data because ‘privacy’).

> I admit that last paragraph may be FUD, but in this case the risk to the stability of the Internet is potentially at stake so 
> largest possible ‘we’ owe everyone a little time exposing the potential issues in detail with any mitigations if they exist. 
> Preparing those who will be impacted for change and then somehow containing the initial  change so if it really does cause 
> hard to contain issues we have a small enough problem its solvable in reasonable timeframes. Anyone who has done 
> operations will tell you that big changes that happen fast are the nightmare you fight hardest to avoid. 

> One more thing I’ll repeat others warning.. beware unintended consequences this must not end in a fight between 
> networks, or governments and DoH providers. If this goes wrong and corporates and other players decide this is a step 
> too far because of the impacts we all know the outcome could be very messy and I for one would rather work to get a 
> less painful and most likely less privacy impactful result. 

> NB: Don’t bite I do like the protocol and I agree that there are some that need it to exist. 

I agree with the thrust of your argument, think that those that seek to distinguish between the protocol and its impact in  
real-world implementation scenarios are mistaken.  The current design is incomplete and lacking in functionality and 
needs more engineering effort in order to address the shortcomings identified here and elsewhere.  Without further work, 
DoH will simply serve to undermine privacy and security, as well as leaving application developers and resolvers that use it 
in a position where they may be non-compliant with legislation in numerous countries  - and so open to legal redress.   

I hope that the IETF recognises that these are legitimate challenges that need to be dealt with so that DoH can deliver 
it's intended benefits.  

Andrew

---

From: George Michaelson <[email-masked]>
Date: Fri, 29 Mar 2019 12:03:19 +0100

Do you believe there are substantive differences in respect of the
legal challenge to Operators of DoH compared to say DoT and DoC?

As to its protocol maturity and risks, Because DoH moves out of strict
53 framing and processing, I think it does have qualitative
differences to DoT and DoC in these terms because it is less likely to
be classic DNS processing by a resolver client. But, I might ask the
same question: Do you see risks different in scale and type to DoT and
DoC?

-George

---

From: Paul Brears <[email-masked]>
Date: Fri, 29 Mar 2019 11:54:27 +0000

Further down the thread it had been said that choosing to use DoH was the same as choosing to use Google DNS rather than your ISP’s:
 >"For the types of home networks you mention, which generally lack professional and dedicated network administrators, DoH does not inherently represent any significant change to the decade-old status quo resulting from publicly-available DNS."

I think the key difference is that on a normal Widows PC you’d need device admin credentials to change DNS provider.
So a child can’t change DNS provider, to get round parental controls, on a family device unless they’ve been given admin rights.

Whereas in the current (beta) Firefox UI, DoH can be turned on without any additional controls, or any technical knowledge.
What’s worse, the UI today doesn’t make it clear that this setting will undermine parental controls.
So a parent, expecting their parental controls to work, and checking the device settings, won’t see DoH being enabled as a problem.

If DoH becomes default then most parents won’t even see the control hidden in the advanced settings, and won’t know why their parental controls are no longer working.

Regards,

Paul

-----Original Message-----
From: Doh <[email-masked]> On Behalf Of [email-masked]
Sent: 29 March 2019 10:58
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Doh] [EXTERNAL] Re: DoH

> The DoH solution (note not necessarily protocol) is missing at least
> two key elements which together would have reduced the immediate panic
> in the implementation. Not to say there aren’t other things that need work just the really problematic issues could be contained or deferred.

> With trusted lists of TRR’s you’d then be able to use the output of a
> fundamentally insecure discovery method. If that ‘trust and privacy’
> were to be selectable say by choice of provider. You get the option to
> allow the local network policy / or not. You can chose to allow
> trusted coffee shops but others may be not in your list because they
> do things that ‘you’ don’t like. Parents can chose to trust only those DNS providers that give strong parental controls. Whatever group you are in many things would be less controversial. Oh, it’s not easy but at least we wouldn’t be in the current position where it is almost certain that a sudden change will occur to a keystone of the Internet.

> Worst case example is that given the billions of queries per second we
> are talking about here and the localisation of content delivery it
> impacts, many terrabytes per second of traffic could / would rapidly
> migrate to less-optimal CDN’s. The distribution of this might well
> break networks, sadly there is no research that can reliably work out
> the full impact. Small trials really don’t help because we already handle small percentages of non-local DNS use. It’s the unknown of what happens if 80% of the users in a single software update change to a non-local DNS provider (especially if it’s one that doesn’t forward granular enough EDNS client-subnet data because ‘privacy’).

> I admit that last paragraph may be FUD, but in this case the risk to
> the stability of the Internet is potentially at stake so largest possible ‘we’ owe everyone a little time exposing the potential issues in detail with any mitigations if they exist.
> Preparing those who will be impacted for change and then somehow
> containing the initial  change so if it really does cause hard to
> contain issues we have a small enough problem its solvable in reasonable timeframes. Anyone who has done operations will tell you that big changes that happen fast are the nightmare you fight hardest to avoid.

> One more thing I’ll repeat others warning.. beware unintended
> consequences this must not end in a fight between networks, or
> governments and DoH providers. If this goes wrong and corporates and
> other players decide this is a step too far because of the impacts we all know the outcome could be very messy and I for one would rather work to get a less painful and most likely less privacy impactful result.

> NB: Don’t bite I do like the protocol and I agree that there are some that need it to exist.

I agree with the thrust of your argument, think that those that seek to distinguish between the protocol and its impact in real-world implementation scenarios are mistaken.  The current design is incomplete and lacking in functionality and needs more engineering effort in order to address the shortcomings identified here and elsewhere.  Without further work, DoH will simply serve to undermine privacy and security, as well as leaving application developers and resolvers that use it in a position where they may be non-compliant with legislation in numerous countries  - and so open to legal redress.

I hope that the IETF recognises that these are legitimate challenges that need to be dealt with so that DoH can deliver it's intended benefits.

Andrew

_______________________________________________
Doh mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwIGaQ&c=QBQnBADTkHi11eP-cEJc_w&r=j11EXA79ztEEyfseWz2YOw&m=F36pkQkj9Obv9Ay8D3GylC7ywhTsOcLnycaXvTkR4to&s=YoMKUnV6PYR2Pc3zm-6nPAN0drbirw4DJUTmxCEvBBw&e=
This message is confidential and should not be copied or disclosed to anyone. If this email has come to you in error, please delete it, along with any attachments. Any views or opinions presented are only those of the author and not those of RM. RM accepts no liability for any loss or damage which may be caused by software viruses and it is your responsibility to ensure that this email and any attachments are free of viruses when you receive it. You may use and apply this email and the information contained in it for the intended purpose only and RM shall not be liable in any way in respect of use for any other purpose. In respect of all other matters, to the fullest extent permitted by applicable law, RM disclaims all responsibility and liability for the contents of this email (including any attachments). Please note that RM may intercept incoming and outgoing email communications.

RM Education Ltd (Reg. No: 01148594) is a company registered in England and Wales with its registered office at 140 Eastern Avenue, Milton Park, Abingdon, Oxon OX14 4SB; VAT No: GB 630 8236 56.

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Mar 2019 14:06:48 +0100

> I think the key difference is that on a normal Widows PC you’d need device admin credentials to change DNS provider.

This again conflates product concerns with protocol ones. Applications 
have always had the ability to incorporate their own resolver library 
and configure it to use servers other than those provided by the 
operating system (cf. c-ares, adns). The concern you describe is that 
some popular applications may choose to do so.

/a