Re: [Doh] [EXTERNAL] Re: DoH

[Paul Brears <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: 29 March 2019 10:58
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Doh] [EXTERNAL] Re: DoH


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

> 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.


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
[e-mail]
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.