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

Thomas Peterson <> Wed, 24 April 2019 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55ABE12034D for <>; Wed, 24 Apr 2019 07:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.336
X-Spam-Level: *
X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gWkvPGjGTHyg for <>; Wed, 24 Apr 2019 07:49:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D26DD120364 for <>; Wed, 24 Apr 2019 07:49:10 -0700 (PDT)
Received: by with SMTP id o25so4978525wmf.5 for <>; Wed, 24 Apr 2019 07:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=sL2y5/r6CB6G2BaXfWvvVHxCL08cCbW9UgJg4BmHjvs=; b=Ajs4O7UTw3YhO1yhJ9lHgCc9iuTKPuMW57t/doMg0Jy4Q5WzvnJPH0mcOkZQ8NvGhR 1mCjktJ5XX+WXe77Y8jRz7imL8PG/g9o3KcjwGP2pQlc1DK8YPw2IP3RxZc1m2hLIv1D BiESz3el6k1rFaIu5KVX6IGfiqsz5UM34eYXMb4EJcK1KQhEwHMubNpYztL+goGz3sIh T5jjOws7lPRVxrljrHwSq4lwKDxJ6zvvYzgb0prwbg+A9+X/Ay1G4eFvPnCMCsgzpSyi BEQxyv7XWVQFVB5LrouW7ISoFKVmayOBGNBCb4KstBR3X3AR9buDTwy5NOTmRNTFLUXx Xl1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=sL2y5/r6CB6G2BaXfWvvVHxCL08cCbW9UgJg4BmHjvs=; b=NpoAHcIfb0XCCOxrdwWtW5o9HXW+sseS4tHadY5/aD5E0eCwU3eis1CRvfggdCbcWv s9mNh4d7h3gceDPBmclZmcCb5I44gj0Hyq6bjTh02MQ1mlq55UfCGbWuagOtXA6635x+ iVAFzrh8nd36CwHSmIPzJaJumbrwzM4BKjulYLYylMbPSfjnmra9/jYgBOgfO2ZGkcpL Ls8kFuKFQ0MH992AKEwx2L7zGGiA+I8ruKP0lmZibjEMfJ8x7jq6kkah3a5BfA2RKYaQ zNQH0lpEjJbGOG41gdQOodPuC1D4t/kkPFuYqPhyGRkaTwet9ic2uBSE3rfdbdUQ9HWC hIQA==
X-Gm-Message-State: APjAAAWy/Ar45nXH42e3LxU7pMbq5JRWwpOFJYod+UG3baVtCzgIgH36 rPCrJDCCvCS533UnS5FaKM1+h0dx
X-Google-Smtp-Source: APXvYqzuOys4+67+Te8kS9SiDDxTy1/2Tomp0wGz3un7AK/5f0biArX3GUfuuNpuPhG2h+I2H+GlOg==
X-Received: by 2002:a05:600c:2198:: with SMTP id e24mr3999105wme.16.1556117349176; Wed, 24 Apr 2019 07:49:09 -0700 (PDT)
Received: from ROADKILL.local ([]) by with ESMTPSA id u6sm35429199wrg.72.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 07:49:07 -0700 (PDT)
References: <> <> <> <>
Cc: Martin Thomson <>
From: Thomas Peterson <>
Message-ID: <>
Date: Wed, 24 Apr 2019 15:49:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Apr 2019 14:49:21 -0000

I agree with Martin on the points around discovery, and as such have 
started an initial draft[0] describing DoH DHCP and RA extensions. 
Feedback from the list would be appreciated, and should there be further 
consensus for this I will also author an additional draft for DoT and 
begin the necessary requests to IANA for assignments.



On 30/03/2019 12:48, Martin Thomson wrote:
> On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote:
>> The reason I didn't drop down to http: is that doing so evokes the
>> <horror> response, even though you are quite correct that the other two
>> methods given in this document do not offer any authentication.
> There is a different reason that I think is stronger.  We tolerate an exposure on DHCP and other network-layer configuration options (like the v6 RA).  The security implications of those mechanisms are well understood and it is common for networks to deploy systems that limit the opportunity for attacks.  Things like filtering broadcast and RA from end hosts are common.
> But the connection to a resolver might be harder to secure in this fashion.  Though it might be possible to narrow the use of unicast port 53 (or 853), such filtering is different.  It is not always the case that the resolver is local in the same way that a DHCP server/relay or gateway is.  For DoH, which might use a service that is completely external to the network, this is more difficult.
> Therefore, it is easier to look at this step of the configuration process as being subject to "untrusted" activity and insist on authentication.  It's certainly true that the only basis for authentication is the assertion by the network discovery phase, for which you have no prior expectations.   However, the property we are looking for is that we are talking to the same server that the network intended for us to talk to.  Thus, if the name of the server comes from the same mechanism that gave us an IP address (DHCP), or the system that provides connectivity (RA), then we at least have that much.
> If your goal is to talk to the resolver provided by the network, then I believe that to be sufficient.
> Hence I would propose a different design for this, bringing DoT into the design.
> 1. The first step requires no new protocol mechanisms.  To discover DoT, connect to the resolver IP at port 853.  If the server produces a certificate that is valid for the IP address of the resolver, then you are good to proceed.  No new mechanism is required.  (Clients may decide to accept any certificate here if they require opportunistic security, but I would suggest that this is unwise for the aforementioned reasons.  That said, it's better than using Do53, so I'd say it's still worth doing except for the fact that this establishes an expectation on the part of DoT resolvers that having a valid certificate is not required, which is dangerous.)
> 2. We add a field to DHCP and RA that carries the "DoT resolver".  When this is present, the client resolves this name using the resolver.  This resolution is unsecured.  The client then connects to the resulting IP address and validates the certificate it presents using this name.  This enables easier deployment of DoT because a certificate for a name is easier to get than an IP certificate (it also enables use of 1918 address and the like).
> 3. We add another field to DHCP and RA that carries the "DoH resolver".  When this is present, the client resolves the associated name using the unsecured resolver.  The client then connects to this endpoint, validates the certificate and proceeds to use DoH.
> We could decide not to do the DoT step, but I wanted to include it to illustrate the symmetry of the design.
> You will observe that this is significantly simpler than the proposed design.  There are several drawbacks, that I will address:
> A. A client in a residential network will not receive this option unless their gateway/relay is configured to relay these values from external network.  The design proposed in the current draft has this property in that the SUDN is forwarded by resolvers that don't understand its purpose.  In this case, endpoints will talk to the DNS proxy in their gateway and not be able to discover a DoH service provided by an ISP.  RFC 5625 points out that it is not generally possible to talk to the external resolver.
> B. This doesn't provide any option for web clients to find the local resolver.  I will separately argue that this is not a valid use case, and moreover that it is one that presents some privacy challenges for clients and networks.  It should not be possible for a web site to be able to use a client's position in the network to access information that it would not otherwise be able to access itself.  Allowing requests to a local resolver might allow access to that sort of information.  Sites are better suited to making requests of configured resolvers.  With DoH, they can make those requests from the client, meaning that the answers will be more suitable for the client's position in the network than their own.  Though this requires that the configured resolver has nodes that are deployed near the client, I believe this to be sufficient.
> I think that problem A is pretty significant.  The SUDN option does help there, but it eliminates the weak "authentication" we have.  For anything in this area to work, I think that we would need some other basis for deciding that the DoH server that is identified in this way is OK.  The only idea that I have, which is a poor one, is to configure clients with a list of "trusted" resolvers.  I don't like maintaining these sorts of lists, but it might be the only way to manage it.  No matter what option we choose here, I would prefer that we look at the DHCP/RA steps first.
> _______________________________________________
> Doh mailing list