Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted

Ben Schwartz <bemasc@google.com> Fri, 24 April 2020 23:13 UTC

Return-Path: <bemasc@google.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89A3A0F58 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 16:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 XOoIDYTHmFft for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 16:13:07 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42363A0F5B for <add@ietf.org>; Fri, 24 Apr 2020 16:13:06 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id s10so13262528wrr.0 for <add@ietf.org>; Fri, 24 Apr 2020 16:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9BuxwhC3/wF3T3JR5G/1MBo7d99OyEjkc60uc7WnIuo=; b=BaTU7jF9q0/QY67NSB7S9iqV8CZQrlCGUcv/Wqs6AWAwoOmPrx/s9p3eznwNzlSy3+ tysHNHIMHawjzw97GL5DzqgI8AQ693N7ELGYr5rCqsDPXFJiYIdiXppQULrM4VrVtO4O U+m5ngSuM8VMXSShseLrHVRyAHCHlmjtjFprOkWuAy/LCBouRwU8gSvIdsLsE3xVosTh qhWjjpogud5UXw2ma49DclYa8EgaAReMSis0LH2GNZvkh+gjKj/TO5HSPWvMrAeDckmq Aze0fMXy/IQaEX7cgRJl9ggiAb4J72mgKTIC7f0g0n3hoNZ4VjSQaFCrdfEFBFLn2lUl +bvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9BuxwhC3/wF3T3JR5G/1MBo7d99OyEjkc60uc7WnIuo=; b=a5A0vvoGWNEnUrTq9fYN+87TDoPycx6frz4/yhk98sTrwfrbTPLegNm/rmXAFAldcD 8XRmlpfjEOAUJ3ta0P75vVJlTmIi2dF71HmOqr/b7S1xGWOxMtvg5CK6vPv31J/0pEF+ WQZCHKIoUHQb/UZ7PJFl0B/mnO9yK5Lnl3sPeOx2HP+kKeyMoaWSXaA11TvmPIQnYdBZ ggUdcaovT3kynk+QIoBgQMa6OP3yo3ywYroE0qWaFKkFlFd+AEc6raVYlV0NVwe+hOO4 tBIaNFpUZqjohljhd4ONR9yTC5s5DsaR8BbiSBIGs2BDXnLDIp/2P/UsEx9zfKpobvBm J08Q==
X-Gm-Message-State: AGi0PuZcExNVgBBHxrvFpdtgbuSn7DLsTOqEJxSMXz7byuqB5N5/8xr2 NaIYOmQJAdJy6H7T92Oa2if2IsXMO0994hgTb4j+3Q==
X-Google-Smtp-Source: APiQypJVjRYB6Er2nTGJ8bHmR7bzH1ozEv0DRisyLSCwqn/qW1JWH+tL1c4cO21r9OVolfpMFg9xj/dMmpxGAOGFxcE=
X-Received: by 2002:a5d:6a8b:: with SMTP id s11mr13582853wru.258.1587769984728; Fri, 24 Apr 2020 16:13:04 -0700 (PDT)
MIME-Version: 1.0
References: <E1091705-3E44-4284-AFE3-824052FBF5C2@icann.org> <CAHbrMsCdch3XN9r0t1kNGPtQv3ctXBH49QOJOsktHth-2WNEfQ@mail.gmail.com> <57727489-B6E3-40A4-9E72-79EB78AC671C@icann.org> <CABcZeBPwoA9O-sr443Woo3U-HbJGsx5asC8gjwDknxPiT86ZnA@mail.gmail.com> <CH2PR22MB208610A6E15C3953EB3EEA58DAD00@CH2PR22MB2086.namprd22.prod.outlook.com> <CABcZeBPGwVzGXhKp-gKphJ+d+cdDnwWcnzVpbTfesUaAhY0-=Q@mail.gmail.com>
In-Reply-To: <CABcZeBPGwVzGXhKp-gKphJ+d+cdDnwWcnzVpbTfesUaAhY0-=Q@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 24 Apr 2020 19:12:52 -0400
Message-ID: <CAHbrMsD02uzm6ogrVzhes-OnxskVF+jqV0LEtzxH_-HWs3hn6A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mike Bishop <mbishop@evequefou.be>, Paul Hoffman <paul.hoffman@icann.org>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f69ba805a411812c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/0I0p3vn7CqwWtRUdNoD8uzAHPqQ>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 23:13:09 -0000

Maintaining authentication where it already exists is important.
Introducing authentication where it does not exist is at best difficult.

Currently, any client that identifies its DNS server by IP address has no
authentication, whether or not that IP address is known to the user.  I
don't think we should try to fix that in this draft, especially if it adds
complexity.

As an example of authenticated servers, the only way for an Android user to
explicitly activate DNS over TLS is to specify a server by hostname.  (IP
addresses are not allowed).  That's a case where authentication exists, and
RESINFO maintains it correctly.  With RESINFO, a DNS client on Android
could use the validated DoT channel to discover corresponding DoH endpoints
securely.

I think this is likely to be the pattern of the future.  In cases where
stub resolvers (or forwarders) are intended to use secure DNS, the server
will be specified with a hostname, not just an IP address.

On Fri, Apr 24, 2020 at 3:29 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Apr 24, 2020 at 12:16 PM Mike Bishop <mbishop@evequefou.be> wrote:
>
>> Hijacking a connection requires being able to subvert connections from
>> that client and spoof the destination IP address.
>>
>
> My assumption was that you would forge the DHCP message that gave the
> client the IP.
>
>
> Getting an IP certificate would require doing that, not from one client’s
>> vantage, but from every vantage the CA chooses to test from.  If the CA
>> tests from multiple vantage points, the IP certificate is a stronger
>> assertion than simply being able to accept your connection.
>>
>
> Agreed.
>
>
> But let’s say we remove the HTTPS path.  What do we do instead?  Do53 is
>> unencrypted and just as unauthenticated.  Speculative DoT is just as
>> unauthenticated, since either you’ll validate against an IP certificate or
>> take whatever certificate is there.  For the time being, all bootstrapping
>> requires an element of trust.  I don’t dispute the weaknesses you point
>> out; I simply don’t see that we’ve found a better alternative.
>>
>
> Oh, I agree with that. My proposal is that we just admit that this is
> unauthenticated and live with it until we have an E2E story.
>
> -Ekr
>
>
>>
>> *From:* Add <add-bounces@ietf.org> *On Behalf Of * Eric Rescorla
>> *Sent:* Friday, April 24, 2020 2:54 PM
>> *To:* Paul Hoffman <paul.hoffman@icann.org>
>> *Cc:* Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>rg>; ADD Mailing
>> list <add@ietf.org>
>> *Subject:* Re: [Add] [Ext] Drafts on upgrading stub-to-resolver
>> communication to encrypted
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <paul.hoffman@icann.org>
>> wrote:
>>
>> On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=
>> 40google.com@dmarc.ietf.org> wrote:
>> >
>> > Thanks for the updated drafts.  I think RESINFO is the most promising
>> path for resolver upgrade, and I'd like to see it implemented.
>> >
>> > The one major change I suggest is to remove the entire HTTPS mechanism
>> from the RESINFO draft.  This mechanism creates a great deal of complexity,
>> doesn't follow good practices for HTTPS, and doesn't obviously enable any
>> additional use cases.  Having multiple competing mechanisms also makes
>> interoperability less likely.
>>
>> The additional use case that was brought up in earlier work is that a
>> stub that wants to do DoH.
>> - It does not need to know how to make requests for a new DNS RRtype
>> - It can use HTTPS as it knows it
>> - It can get a response that can be authenticated
>>
>> I understand the desire not to allow unauthenticated HTTPS because of
>> best practices. We can remove that from the draft, but then implementers
>> will likely go ahead and implement it anyway but without guidance about the
>> results. Note that we are only talking about unauthenticated HTTPS *for
>> this one use*, not in general.
>>
>> > If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism
>> could always be added in a later draft.
>>
>> Some people said it was insufficient because of inability to authenticate.
>>
>>
>>
>> But the HTTPS mechanism is unauthenticated as well. And even if people do
>> use IP certs, then they mechanism by which they get the IP is largely
>> unauthenticated.
>>
>>
>>
>> I agree with Ben; this  mechanism should be removed.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>> --Paul Hoffman--
>> Add mailing list
>> Add@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
>>