Re: [Add] [Ext] Updated charter proposal for ADD

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 15 January 2020 23:13 UTC

Return-Path: <brian.peter.dickson@gmail.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 A8CD9120113 for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 15:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u_sXTivA1ea4 for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 15:13:30 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 3710D120044 for <add@ietf.org>; Wed, 15 Jan 2020 15:13:30 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id g15so11544350vsf.1 for <add@ietf.org>; Wed, 15 Jan 2020 15:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PR2h+AbLgVAwvIFXeUd6EPdH1TAX5LB0/kGAR9zkELQ=; b=juOYV9Yu6beP4hf970CoiQ7nzWuCGa278POrniH1cKTjCmW3lpKnVjKiOGockBcmeG RtmOERIhwf5CzWDDir+I1rnyiJYI2n9HpnppMNoZnJZLwPzwbWPzSAifl8cXqwnW9QQI 6VJw6rsPiV5kd4rOwXRPx+n8EbO4mSnW1TgV5AcMoDFNReBc4CZS67YQbVy6NlS7Rp4e 3FanR4TA7th+cdF6TcVCSFqSyZwUNkDwDyT5VQBJf5iru8KLUJq5fnquhAh1nQhb4PtQ GQFEPL6Vi0Ot79HcqKWdIlrI6dBnBdgEIAuFLn7efTDLxpx3aHQ1tb9/4uw0Hw68qlO5 EtFw==
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=PR2h+AbLgVAwvIFXeUd6EPdH1TAX5LB0/kGAR9zkELQ=; b=DH5Qwq4NN8qwd2VKlZFmZR6m3M4lz6mdh5gs6ooELLFoUpordc0fi5HdX77LrUPONQ IuaH7K5NlQcqVOZJ95qbAwYbuP5pim67KxulbxRhsxFHwrEm7mrXLdX5gaZKbK3Xps4u FG0UYEIfCmD+GVnMQUG43wqpyMI1Bnaji0pnxtDa6ErdMy/VAHEzxwaZaKO/wuIKo1yI SvBpfDiDDCzA8G5MCmP79dXed6L8ovHMmG+RdNphHgpXHQ5uRCsZJyMdNSoqMjqbmWwU M/4tn1QqUb/3hFQvY+MkOK1g4XcIxVPl+sMzcZwpdYUNDdL7kH1BM/HDxoTG1E3cs4va crHQ==
X-Gm-Message-State: APjAAAVkGLImJ/rB8Ex6JK00VzCegsCDqeSQ6gsc25WysVRwfru5TPuX 7xM9/IHqAdLIXYL++4DNFirW50F+txFIyWPwfEzb7ten
X-Google-Smtp-Source: APXvYqxi2b42a1vveU2CvHwAueNiPZmNFT4YYcl1ZV3xoHqGlpx/65NiDEkZ4VYxPvch6yTymEnokYGDdHK+001PcCY=
X-Received: by 2002:a67:f995:: with SMTP id b21mr6007433vsq.199.1579130009284; Wed, 15 Jan 2020 15:13:29 -0800 (PST)
MIME-Version: 1.0
References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <AD6E599F-96E8-44FC-8A05-8BFD2F659129@icann.org> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <CAChr6SzcuomCFisPhLHYfQGzbR2=yYhtsGHV8+kd5gCdJn+ABA@mail.gmail.com> <LO2P265MB05730A944404EFD86DF99E8CC2370@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CAChr6SzygCAMGUXmOL9Hb_w5CgjeFK30KodystPYPt4jD6Fkeg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAH1iCiqr9NmudeRLf9QMPaPTUBcQmi=sYGhN397oGM1b+YMPNw@mail.gmail.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> <CAChr6Szx_QRkzNU+ZHu2=HJG4oC59YbHOvctrp3sKqsgD0TZUg@mail.gmail.com> <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com>
In-Reply-To: <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 15 Jan 2020 15:13:17 -0800
Message-ID: <CAH1iCippzARhk53A-tCyPvvQYKWNbvcorrxKORvqkEcfOriWfw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Rob Sayre <sayrer@gmail.com>, "STARK, BARBARA H" <bs7652@att.com>, Andrew Campling <andrew.campling@419.consulting>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041f389059c35dbd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/A8lZW7nOPSeMf4liaPRmd6YBBzs>
Subject: Re: [Add] [Ext] Updated charter proposal for ADD
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, 15 Jan 2020 23:13:32 -0000

On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon <mellon@fugue.com> wrote:

> On Jan 15, 2020, at 5:20 PM, Rob Sayre <sayrer@gmail.com> wrote:
>
> The point wasn't limited to home routers, although it does apply there.
>
>
> OK.   For an enterprise user, the easiest thing to do is just get a cert.
>   The IP address doesn’t matter.   If you want to use ACME, you might need
> to do some gymnastics, but you can make it work.   An operational document
> that describes how this works might be useful.
>


> I don’t think there’s any new protocol work to do here.
>

Maybe, maybe not. Or maybe not new protocol work, but separating which RFCs
are informative vs normative might be a big issue.

Specifically, it has to do with scope, when considering the question of
certificate validation.

The scope of the WG charter is larger than WWW use of DNS.

The related scope question is whether it is appropriate to rely exclusively
on the WebPKI rules (including trusted CAs) for validation of X.509
certificates used for DNS.

This has to do with MTI, and interoperability. It isn't going to be a
successful outcome to the WG if the result only works for browser clients
incorporating WebPKI elements (trusted CA set, and revocation via
OCSP/CRL/CT exclusively), as opposed to use of DANE (single trusted public
DNS trust anchor, and revocation by unpublishing DNSKEYs in DNS) and
possible use of non-public DNS trust anchors.

Brian