IETF Logo Mail Archive

Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

Eric Rescorla <ekr@rtfm.com> Tue, 30 June 2020 16:00 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 D62893A0BB5 for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 09:00:51 -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=ham 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 jzSgwrvdTfeF for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 09:00:49 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 61D813A0BAE for <add@ietf.org>; Tue, 30 Jun 2020 09:00:49 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id y18so11702469lfh.11 for <add@ietf.org>; Tue, 30 Jun 2020 09:00:49 -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=woViuGH2KgcuHEAN3Y5oHxYSJhfQ/aWxkFMoeQuHWHI=; b=0YW5RPoZ98PVMS0vfvgi95d+ZoCy9dR8paaHCmXPYTlkbhR2mPLQG4TrPvCEz5wm21 YlHOY1JlFTAeZVEUFeFdU8gb1cByGoMQeQ0yvuFiX7NYckomaZjBxtKpILBKHZC4o2VH iSIU/T3AeB7ngearb/lfXQFXiOp1+jkKj/kZIddkplox7yoB4Lp0NLntyoFJm3gpKI47 eBGLpZBjhW5kBAcqzZGEp29ZjiWAIUz1ohpYHKzswA/8sZi9KIivvoLr5IhUNEZ88DI9 runq6cn9iRrPby4NfFoelVFHeIzu7/ui+mbab1Bf+QKLlsI+RvtIou7NyBxz9v1hUHC8 VQgQ==
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=woViuGH2KgcuHEAN3Y5oHxYSJhfQ/aWxkFMoeQuHWHI=; b=AINacHzLgSNM+uon9ldHFij/35O8s2o+AxbLhQqRj4ulKoDpZEQZHdRbC8heESB1RC dBUvzcL1xVm5fNBAGFEiWDH+PxnZgzafu/hM0wWV4s/zZ/oC5fBAGc525KSJUEO+0ZcR 0GbgrEJDsFxnvVGaroLs7tod1Bx1wB2/No8ioI3cWn0RA34HQdsd8FLGiYvjc6l04OGq BFHNoZKwRPGLYc+WfZet8tJEBLiwcPhYsOxQjANbl1T4+jzg7PKmL1P7B5YsKWzIig38 BhVP0qb3zZm1CXHmqVpywijFBL75FpPFgAXWtW1tXxpKnXquOk74WBVGu6L3EWfddE8p OmuA==
X-Gm-Message-State: AOAM530XutO1NaMqn4Er2l1cGdnu8i7gq3K2f2Tep+zC/jRlcjzOpdYR ctNnmWEFaS/4gy8vrouuIV07+RG+Rm2uOUZ3T0sCgw==
X-Google-Smtp-Source: ABdhPJwmGyiChwYPx/MMz+3BsuFiEijeDIacZrRj1/D3/9R6LCscaOk8bp3CbwTbCUW4BDBWrYpD0gTFwN60p6H+z7Y=
X-Received: by 2002:a19:83c7:: with SMTP id f190mr12562534lfd.14.1593532847435; Tue, 30 Jun 2020 09:00:47 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <bd78f54e-038d-9cff-b6a8-c9c6323ed5f5@redbarn.org> <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <CABcZeBP8okFjJZk6+PYnTRqDi+KW+=4eT9niRZKkQ00THgL81g@mail.gmail.com> <CAFpG3gdn5JLf7wFpF2ZOVpGzDF9=y4RXsdZbztTJP8y71v80oA@mail.gmail.com>
In-Reply-To: <CAFpG3gdn5JLf7wFpF2ZOVpGzDF9=y4RXsdZbztTJP8y71v80oA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 30 Jun 2020 09:00:11 -0700
Message-ID: <CABcZeBMG9P8wpK8PAH_fQkdC_N7xrqoOewpYO1dw4GSwBQEBqw@mail.gmail.com>
To: tirumal reddy <kondtir@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f46df05a94f479c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/voVTeyBB82B6GD9uiXHFX6ei2Zg>
Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers
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: Tue, 30 Jun 2020 16:00:52 -0000

On Tue, Jun 30, 2020 at 6:44 AM tirumal reddy <kondtir@gmail.com> wrote:

>
>
> On Tue, 30 Jun 2020 at 18:28, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <paul@redbarn.org> wrote:
>>
>>> On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote:
>>> > Hi Paul,
>>> >
>>> > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
>>> > > Eric Rescorla wrote on 2020-06-29 20:08:
>>> > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <
>>> mglt.ietf@gmail.com
>>> > > >
>>> > > > <mailto:mglt.ietf@gmail.com>> wrote:
>>> > > >     If the lookup takes as input the IP addresses or something
>>> provided
>>> > > >     by the ISP (like the local resolver IP address), the resulting
>>> chain
>>> > > >     is likely to be from the ISP. DNSSEC is needed to assert it.
>>> > > >
>>> > > > Why do you assume that the IP is delivered securely?
>>> > >
>>> > > because dnssec allows me to verify end-to-end authenticity of
>>> > > name/address bindings (and other dns content.)
>>> >
>>> > DNSSEC allows you to be sure of the veracity of what comes from
>>> DNSSEC, but
>>> > in this case the IP address didn't come from DNSSEC.  It's not DNS
>>> content.
>>>
>>> i have badly misunderstood.
>>>
>>> the way i know that the ip address provided by the isp was delivered
>>> securely
>>> today is because off-net DHCP forgery is hard,
>>
>>
>> Let's start here:
>> I agree that off-net DHCP forgery is hard. However, once you assume that
>> you are off-path, then Do53 interception is *also* hard. So for this to be
>> useful you need an environment in which the attacker is able to attack Do53
>> but *not* to attack DHCP. What I'm asking for is for someone to define that
>> threat model precisely so that we can design protocols that match it.
>>
>
> The various possible attacks in a home network are discussed in
> https://tools.ietf.org/html/draft-btw-add-home-06#section-9
>

As far as I can tell, what this text says is that authenticating the server
based on information received in DHCP is not useful.

-Ekr

v2.23.0 | Report a Bug | By Email