Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

Eric Rescorla <ekr@rtfm.com> Tue, 16 July 2019 19:53 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 274BF12014F for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 12:53:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 c-dfc2UMgPjE for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 12:53:32 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 B299712024D for <add@ietf.org>; Tue, 16 Jul 2019 12:53:31 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id b17so14638417lff.7 for <add@ietf.org>; Tue, 16 Jul 2019 12:53:31 -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=8zwwQvHJ4X/X3gQjct/JOKjfht8dbcpwUS2kueR2eKw=; b=cAwexXGWWCCjuSWOf2/CWNmAGTZ5LoYy+5RDeKkMnPGhAgCG+PEWvU9JwmYTNBmoVE x02iKi26FBOLcrWDHh6EsO061u8LF9Pdqi++gRY+QctGiMI9INYTYarw12emmhvYEi1i 8rKBL3jYOAdYef71bOHFw6tmcMwzB7eXQ78VrBYHYjoAzQbh9TkFfZY9NF3MgnZU3H0B vv8/PGKG1sdr9u6JYU6VBs7CKipc4WnzshjuhjP8I2cvbNsVK7AgRnpGVLuWRhFGkNHi e0V5rL7UlEJy9Pbpo8/IW6sEe42nfuyxtuFoiaJS68ARqek10QjO1NVSArGMRcUl0z09 XjBA==
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=8zwwQvHJ4X/X3gQjct/JOKjfht8dbcpwUS2kueR2eKw=; b=YeBlaJ/8OqQ6yvr0qqw5fzQmZws6nKcxEhp2rOmhV/TgGKGDRvb4beodWS9m+EHfQX TzdA77/P2EoTzCSUt1feUg+cuWhQpLaUCpwa2/e4cBMlLiq9x2eBymy/RcX7rl3LnDQE t/lLiNffLQoOPkD0vLpeZvESbtr5u717QPYOzurSjhepn7jTTvszt/j3G4Y9SVOkTZr7 kTNXOzzHTI+xwPlv0QPD1IYm4wgQNeFsemKfQhZ9W7XStQUhPp3GCuZmyE5Cso1hT/p1 cqK8/EVqQ4UD+kQCkThnNGDKSEKrmhdegZ/Rqq4LFlDf4wcAJg3mSZdXk/x9IKyNCHZ0 J8Ow==
X-Gm-Message-State: APjAAAW+2NM9Rv/YEl91HXfJkRk1G3pdUxr/wTS0GpeE18mHA3D3eX4p 2w5K72GO5Jajc6pqnWUkG8dlA2b5J3OrDpj/Qkk=
X-Google-Smtp-Source: APXvYqwmgj9wU8siU439jpskKhYIB0waYu/dfJRheA3aynvUbQftacIwZpTRY6Hhojoop5cm56577bgjbWF6BW0kXBM=
X-Received: by 2002:ac2:5336:: with SMTP id f22mr15161064lfh.180.1563306809967; Tue, 16 Jul 2019 12:53:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6SwEUz9MrdRA0bnv9f-oNi0oUHkfRKjd9-o6jwhuckLXdw@mail.gmail.com> <CAFWeb9LNdT=EYVKTsYDxcBCQKoQFNShKotYtWujt4U9GA-V1mg@mail.gmail.com> <CAFWeb9+eWKSKY9O2JLn9-0+Zq7hrD48F-y+Y4T-iRaaF0vtdOA@mail.gmail.com> <A45F4F74-D6C1-435A-A52F-C2DEA82E2999@sky.uk> <CAFWeb9JVBj+Yehup5q4v9X-7XDY+02frd-04AQGL2HoSLON2qA@mail.gmail.com> <CABcZeBMY9q9vKGse1svzbvXF_dSHA+9q06j4ugDVCZP9VT1koQ@mail.gmail.com> <CAChr6Sz5Rfz=UxOYuPguSvVK2HCX2ZoA1-FytW7+EOUxN8y46Q@mail.gmail.com> <CABcZeBNB7ASu2U3ZMBZ+OOxEhbSnhDXwFN3Lsex1uzVSDv3R=Q@mail.gmail.com> <CAChr6SwEwRRX7BA6ZCeBuC93hFxbfi3d7G_3G3VA7Lm09yuneg@mail.gmail.com> <CABcZeBNa97Vb6Fw-fMhoZnMezGtm3nJODENN4=XXsz7GWxf2Cg@mail.gmail.com> <CAChr6Sxm__NroZ92v4HL_6iCa62fwYgNw9r8ZDAxCdzVwNoDGw@mail.gmail.com> <CABcZeBMxQgDZJs3BQkb7xiN6Gm=joBqLmTnHCO+TMdKQyUepOg@mail.gmail.com> <CAChr6SxN+72tY6_6tw-TeBWeYh4XQr-VRip_2LQh3Mnsk85GPw@mail.gmail.com>
In-Reply-To: <CAChr6SxN+72tY6_6tw-TeBWeYh4XQr-VRip_2LQh3Mnsk85GPw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 16 Jul 2019 12:52:53 -0700
Message-ID: <CABcZeBPNevTZDXXXuRS87+YpZ8xY+Y79inW2x0AmPL2Hd9xNmQ@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: Alec Muffett <alec.muffett@gmail.com>, add@ietf.org, "Dixon, Hugh" <Hugh.Dixon@sky.uk>
Content-Type: multipart/alternative; boundary="000000000000155c00058dd1bbd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/YpX0E46I2jpEPe3tSizi0qEp2Ns>
Subject: Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00
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, 16 Jul 2019 19:53:40 -0000

On Tue, Jul 16, 2019 at 12:37 PM Rob Sayre <sayrer@gmail.com> wrote:

>
>
> On Tue, Jul 16, 2019 at 12:28 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>>
>> Aside from that seemingly obvious conflict, it doesn't seem like
>>> DNS-based solutions would really work very well for these benevolent
>>> applications. It's sort of like using a coffee cup as an umbrella--it will
>>> catch some rain, yes.
>>>
>>
>> I'm not sure how relevant this is, but you seem to be assuming that
>> people are actively trying to evade these controls.
>>
>
> Well, they are, but your point about voluntary participation is different.
>

Some people are, some are not. In case it's not clear, my interest here is
in providing DoH/TRR for people who have not explicitly decided they want
some sort of non-transparent DNS service while avoiding changing the
experience of people who have decided they do want some sort of
non-transparent/filtered DNS service. What we are trying to do is figure
out who is who.



> Obviously that's true in some cases, but if I point my DNS to Quad9, it's
>> because I *want* them to do malware and phishing detection [0], and so I
>> have no interest in evading that. I'm not aware of any inherent reason to
>> believe that would be ineffective.
>>
>
> Yeah, I think the question is whether a user would /also/ want that task
> to be unencrypted. That doesn't make much sense to me.
>

Ah, I think we are now converging on the relevant point.

Taking a TRR-style system out of the equation for a moment. Suppose that
what I want is for all devices on my network to use a filtering resolver. I
don't expect any evasion because they're all my devices, it's just a matter
of convenience to centrally configure it. So what I do here is I configure
my DHCP server to provide the IP address of that resolver. Now, those
devices do unencrypted DNS because that's what everyone does. Now, suppose
that resolver starts offering DoT. How do my devices learn that
information? The resolver could tell them over DNS but then we have a
straightforward downgrade attack from anyone on the network. Do you agree
with this so far? Do you have a proposed solution?

-Ekr




>
> thanks,
> Rob
>