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

nusenu <nusenu-lists@riseup.net> Wed, 03 April 2019 20:35 UTC

Return-Path: <nusenu-lists@riseup.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300E120189 for <doh@ietfa.amsl.com>; Wed, 3 Apr 2019 13:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFU2YONGBQ94 for <doh@ietfa.amsl.com>; Wed, 3 Apr 2019 13:35:01 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6662E12006A for <doh@ietf.org>; Wed, 3 Apr 2019 13:35:01 -0700 (PDT)
Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id C93FB1A0200 for <doh@ietf.org>; Wed, 3 Apr 2019 13:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1554323700; bh=IQJs9VD2BUTQFMVBPZoCipFkS3q0zCl/nskmLhDdXLg=; h=To:References:From:Subject:Date:In-Reply-To:From; b=QWdvw5CUoaRz75kLzwhhddMe6HTEgVTcpnG6TE6LuycKGe+xVYesN+os4BiVQUhIq TydnDzA9FKJjP4WaElLTdIDTQ4cL89S70nC/lKRcbcUxq58gMOmY7UrLNWRoTAlbvG fqlnv09ezwp6bemB5EXa1mEu0RlL67Y8OBZVPEPE=
X-Riseup-User-ID: 2F096B0E20E4639861B096222038CBA9FC896A216B2DABAC1BC27F93D17E2E6E
Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id F0FAC1202A8 for <doh@ietf.org>; Wed, 3 Apr 2019 13:34:59 -0700 (PDT)
To: doh@ietf.org
References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com>
From: nusenu <nusenu-lists@riseup.net>
Openpgp: preference=signencrypt
Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA==
Message-ID: <e465a67e-d50c-2341-3b0d-7433055d4bcf@riseup.net>
Date: Wed, 03 Apr 2019 20:34:00 +0000
MIME-Version: 1.0
In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1MrQVr6CAyrLTUnT85bXXtDh3Pme7SzF0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/sRrsfOg49fyrsVWKWUsnvrIdHEY>
Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 20:35:03 -0000

Martin Thomson:
> 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. 

+1
thanks for writing this down. I agree with your reasoning
regarding the potential external position of the resolver and
the increased attack opportunity/exposure (in contrast
to the mostly local DHCP attack surface).

I'd also like to add that even though most clients probably use DHCP to discover
DNS servers, not all do, and therefore assuming it is fine to use
an unauthenticated mechanism is fine because DHCP is unauthenticated as well,
is somewhat flawed.

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

this makes sense to me.

> We could decide not to do the DoT step, but I wanted to include it to
> illustrate the symmetry of the design.

I'm in favor of keeping the DoT step since it provides a path for
deployment even before the new DHCP options are implemented/available.


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

Agreed.




-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu