Re: [Doh] [EXTERNAL] Re: Authentication in draft-ietf-doh-resolver-associated-doh-03.txt

["Winfield, Alister" <[e-mail]>]

On Tue, Mar 26, 2019 at 6:26 AM Patrick McManus <[e-mail]<mailto:[e-mail]>> wrote:

right. The weakness here is that validating a name that probably comes from an unauthenticated source is not a very strong signal. That seems inherent in the draft, but maybe worth calling out more explicitly.

Right.  It typically comes from unauthenticated DHCP or RDNSS.

One thought I've pondered is whether there is a way to apply policy to the hostname in the DoH template URL, as that is an authenticated hostname.  For example, clients could validate against a blacklist of known-bad DoH server hostnames/domains.  This may not scale well enough to be viable.  But we are inherently getting unauthenticated data from an unauthenticated source.  But that unauthenticated data is something which is possible to authenticate and possibly authorize based on the hostname.

You could equally state that the user has to ‘approve’ all new DoH templates. Each has its own issues and in any reasonable scheme its likely you’d need both. One to capture users approval to use a particular DoH provider (including accepting their privacy policy t&c’s whatever). The other so that some form of policy protecting the user from malicious DoH can be applied. The issue is as ever managing such lists without creating the ‘click through’ problem on the choices side.  (read users never read stuff that pops up too often). Or issues with the curation of the blacklist and arguments on what is malicious and what is good for the user.

(Next is a very early thought so I may yet find a reason not to like it)

Another option that I’m liking more the longer I consider it is a notary mechanism. This is like your blacklist but has properties that avoid the who audits / polices the lists. So your notaries provide white and black lists for DoT/DoH even Do53. Anything outside the list SHOULD present something to the user with the policy information provided. Yes that could be lie but that’s not something we can fix.

Not saying I’ve thought this through completely but its feels scalable and doesn’t significantly impede new DoH providers. Users will self-police the notaries and that side can be as simple or complicated as they like including having multiple lists with different privacy properties.

A similar model is done in Provisioning Domains where unauthenticated PvDs come from the network and are used to construct well-known URLs:  https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-04<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-intarea-provisioning-domains-04&data=02%7C01%7Calister.winfield%40sky.uk%7Ce5888ce57e4d4e46148d08d6b23cf5c8%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636892372261334679&sdata=A7Z7O%2FO6qU7r54%2BaItzHeIfdDP2ulQ%2FfPp8LZ3QSc3I%3D&reserved=0>

How to make this practical is where I get stuck.  :-)

       Erik


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