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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 01 July 2020 15:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5EA513A101E for <add@ietfa.amsl.com>; Wed, 1 Jul 2020 08:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jCuk88cuuDgi for <add@ietfa.amsl.com>; Wed, 1 Jul 2020 08:39:08 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53B03A0F55 for <add@ietf.org>; Wed, 1 Jul 2020 08:39:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E4F3B389C2; Wed, 1 Jul 2020 11:36:18 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uWNjq7OvEsir; Wed, 1 Jul 2020 11:36:18 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F5F2389BE; Wed, 1 Jul 2020 11:36:18 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E01AB3DE; Wed, 1 Jul 2020 11:39:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>, tirumal reddy <kondtir@gmail.com>, ADD Mailing list <add@ietf.org>, Paul Vixie <paul@redbarn.org>
In-Reply-To: <AC1FE98D-8F0E-44E9-98EF-8DD5FF7520D5@fugue.com>
References: <CAFpG3gdiidmjxoauBw56ZybRabB6JET1Nh5dzTLQq1k0ZAn6Uw@mail.gmail.com> <AC1FE98D-8F0E-44E9-98EF-8DD5FF7520D5@fugue.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 01 Jul 2020 11:39:05 -0400
Message-ID: <2033.1593617945@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/3j2irvjnuroGkskWmKCH50Yp9ik>
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: Wed, 01 Jul 2020 15:39:12 -0000

Ted Lemon <mellon@fugue.com> wrote:
    > On Jul 1, 2020, at 07:11, tirumal reddy <kondtir@gmail.com> wrote:
    >> Secure bootstrapping methods for IoT devices are discussed both inside
    >> (e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).

    > Indeed, there is a lot of interesting work going on in this space. The
    > idea that devices can’t be trusted is accepted by everybody except the
    > people whose business models rely on snooping, and I expect the state
    > of the art to improve continuously.

    > That said, commissioning protocols are ways of making link security
    > (e.g. 802.1x) more usable, and have nothing much to do with DHCP. They
    > are generally one-time unless something goes wrong.

While what you say is true, it misses an important point.
Those mechanisms that result in the device having
  a) an identity
  b) a trust anchor to validate local resources

mean that other management protocols (such as DHCP!) can be done securely.
We never could get DHCP security to work, because device never had identities
we could leverage.

This is far afield from whether a *browser* should use a CNAME rather than a
new RR-type for discovery.  It feels to me DNS is being used as a hammer
because browsers don't have access to DHCP.

The same might not be true for more integrated devices, so it would be nice
to have more network focused solutions, and I think that this WG is going in
the right direction there.    I would prefer that OSes took on that mechanism
too, and revealed those choices more clearly to things like browsers.
(that would make me more tolerant of this pragmatic CNAME hack, if I saw a
way in which it could go away)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-