Re: [Add] publication of DoH Resolver policies

[Petr Špaček <[e-mail]>]

On 28. 05. 19 18:36, Winfield, Alister wrote:
> It would be wonderful if every malicious domain was known prior to its
> use, sadly except where a DGA is known that’s not the case. So it can be
> useful to have a little historic information to see the extent of the
> issue once it’s become known.
> 
>  
> 
> It’s also true that with performance issues unless they are very obvious
> (eg impacting say Facebook, Google, Amazon etc), operators necessarily
> rely on analytics or customers to complain. Given issues can be
> transient or periodic only a historic record can provide insight into
> the root cause.

I disagree, it is not corrent to claim that blacklists are not useful
becuse the black list needs to be filled in first. For example e-mail
spam lists often get domains blacklisted in _minutes_ from beginning of
spam campain.

Sure, it takes some time to get bad domains on blacklists so naturally
there is a window of opportunity for attackers, but security is not
binary at all and closing the window as early as possible is the very
nature of Internet security.

Once domains is blacklisted it is useful to block it at various levels
(or just log it for a while), depending on situation.

Petr Špaček  @  CZ.NIC


> 
>  
> 
> Alister
> 
>  
> 
> *From: *Add <[e-mail]> on behalf of "Livingood, Jason"
> <[e-mail]>
> *Date: *Tuesday, 28 May 2019 at 16:43
> *To: *tirumal reddy <[e-mail]>, Jim Reid <[e-mail]>
> *Cc: *ADD Mailing list <[e-mail]>
> *Subject: *Re: [Add] publication of DoH Resolver policies
> 
>  
> 
> First – thanks for the pointer!
> 
>  
> 
> Comment – things like ‘logging’ seem very binary. What about default
> logging = no except if FQDN = malware C&C, in which case yes (to support
> notifying the end user of infection)?
> 
>  
> 
> *From: *Add <[e-mail]> on behalf of tirumal reddy
> <[e-mail]>
> *Date: *Monday, May 27, 2019 at 9:12 AM
> *To: *Jim Reid <[e-mail]>
> *Cc: *ADD Mailing list <[e-mail]>
> *Subject: *Re: [Add] publication of DoH Resolver policies
> 
>  
> 
> On Mon, 27 May 2019 at 16:53, Jim Reid <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 27 May 2019, at 11:59, tirumal reddy <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > If the DOH server provided by the network offers the same level of
>     privacy preserving data policy as the DOH server pre-configured in
>     the browser, Why shouldn't the browser use the network provided DOH
>     server ?
> 
>     How could the browser tell that both DoH servers have the same policy?
> 
> 
>     How does the browser (or anything else for that matter) know what
>     some arbitrary DoH server’s privacy preserving data policy is? Where
>     will this be documented and published in a way that a web-based
>     application or the end user can understand and then make an informed
>     choice?
> 
>  
> 
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-03#section-10
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-bootstrap-dns-server-03%23section-10&data=02%7C01%7Calister.winfield%40sky.uk%7Cd36e8632ef774a63e75608d6e383483f%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636946550340220810&sdata=8%2Fkda0%2B9qoR%2FljDojoEKu%2FGQpol%2BhJl0PtuIwASKPUY%3D&reserved=0>
> defines a new privacy certificate extension that identifies the privacy
> preserving data policy of the DNS server, it is in a machine-parsable
> format.
> 
>  
> 
> 
>     Now rinse and repeat that for other server-side policies: data
>     retention, GDPR compliance, DNS filtering/blocking, TLS session
>     resumption, ECS behaviour, QNAME minimisation, NXDOMAIN rewriting,
>     query-related adware, etc, etc.
> 
>     Oh, and if some DoH server says “I do QNAME minimisation” (say),
>     does the browser or end user simply take that on trust or would they
>     somehow be expected to verify that for themselves?
> 
>  
> 
> End user typically does not trust DOH server in a untrusted network
> (e.g. public WiFi network) and may only use the DOH server provided by
> trusted network (e.g. Enterprise, Secure home networks), similar to the
> way users disable VPN connection in specific networks and enable VPN
> connection by 
> 
> default in other networks for privacy. In addition, the privacy
> extension includes a URL that points to the security assessment report
> of the DNS server by a third party auditor.
> 
>  
> 
> Cheers,
> 
> -Tiru
> 
> 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