Re: [Doh] [EXTERNAL] Re: DoH

[<[e-mail]>]

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