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

Eric Rescorla <ekr@rtfm.com> Fri, 24 April 2020 19:29 UTC

Return-Path: <ekr@rtfm.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 EF7113A08D2 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 12:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 C_w3KQDoYPzj for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 12:29:17 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 B98BD3A08C7 for <add@ietf.org>; Fri, 24 Apr 2020 12:29:16 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id g4so11184002ljl.2 for <add@ietf.org>; Fri, 24 Apr 2020 12:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L5B1dHnuL3ET6RMiDpjA6ob5zGZHRBLZghpen2/1UA8=; b=BwOttvQTKG6yGyFcQ/slWumG0iF2x/nnCi0P/PlpkMgdTI6fRX4YRxbWfx1QouB5W/ tz0mUwOCi/fCqHbzrAEpPQlMwpE3UCBnJhHwQM4NBt0QRpFxhQvCJiDyMTPD0A6f+wJT J9Z3ibR5ycVdPWEp8rDnKSEJ1zfs8wZv2m06Ra7z4RXPS71Rou1iG70VPZlZ6keSKvLD wHdwIA53A6/8hAaWUV0TJyJj470b6+8U+fJ8GYehBo9OmI41X+nO7vjesWCT8G9mzMf/ nJQ2uWZMwUlVjGQmjv9R8ZM1kEjkbimDNRWj+46Jp+0n6VnN+14vxOgs5EpzZAuCA+6l AWbQ==
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=L5B1dHnuL3ET6RMiDpjA6ob5zGZHRBLZghpen2/1UA8=; b=Q8k+y2SA+wFK4BAcnd6d8dcO3y9RFv2KdCyYCDHMNnngACpII17r5Nw7CiKRjyE/52 PTEXCjrz8zAuBfA/f18Qd9RVMfOkzc3e3/5H7gkTg4rQoZLA+LZqvluJQSgSTI6zYXZw epo260/HhJN1TPdYp9hRG0HIG9IljEnOpTalMLRTLG/x5GPzfoD10ecfsFd/PszJsCc7 FRzFf1Zp0N/xE2IzIeLuHCg8FqHf1THuyrfyah2rsGoFmmRfGCxvhXvGeZcao7h7T/1M D/D+pPldNItnZsSsJ5I1CVQrrV5ADcPV1I/FTCAQid4NMWzcBxu7seZbP+EF1VYP5AOq KBbQ==
X-Gm-Message-State: AGi0PuZK9oIQQigvRn16AMYB6rV89on512lMKpdAPy9Io5/8isExqUXJ JQVLlEl2Ww46/UvSNAXBU8V7duySyZBS+fPrdshZAA==
X-Google-Smtp-Source: APiQypKQ1rHrkKZvZEaYM6SWQvnvwW2MioWKLWCDjYSBeWK0Gcht8JSyrmfIw8HWeNlU9Y1hSQzMIlHf8soApNhGw+8=
X-Received: by 2002:a2e:9dcd:: with SMTP id x13mr6501599ljj.120.1587756554796; Fri, 24 Apr 2020 12:29:14 -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>
In-Reply-To: <CH2PR22MB208610A6E15C3953EB3EEA58DAD00@CH2PR22MB2086.namprd22.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 24 Apr 2020 12:28:38 -0700
Message-ID: <CABcZeBPGwVzGXhKp-gKphJ+d+cdDnwWcnzVpbTfesUaAhY0-=Q@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Paul Hoffman <paul.hoffman@icann.org>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007058c405a40e6181"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/lJBF5-ZHWw3Ryv_s-j3zwsNZbTA>
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 19:29:20 -0000

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