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

Ted Lemon <mellon@fugue.com> Wed, 15 January 2020 23:33 UTC

Return-Path: <mellon@fugue.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 3C90512008F for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 15:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=fugue-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 SaXAzL51W7eO for <add@ietfa.amsl.com>; Wed, 15 Jan 2020 15:33:19 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 20EB3120044 for <add@ietf.org>; Wed, 15 Jan 2020 15:33:19 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id 21so17495088qky.4 for <add@ietf.org>; Wed, 15 Jan 2020 15:33:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Sc75jWdNzD1qCaBfOCvQyxisQbbgxmtfzu2nMqf1Jhk=; b=M5nkWr06toAgGRL2vlPWSYaqqKWFj9k3B5EQ+khnDuJJbWKchkUEBxO7cirLfP5w+0 LknxnV02Q5uPPyUBIvfTlZcM7S/x0ERLwPTHuPx14I7aYXeV6Nz1fqgIQiXsmXOHSHkW +wCJZxIqRWfdDisAw0cz/NhpoXfm4WYb49UOpIk1fSz0qaj2BKV3idgig2f0qRGQjeYs ztD0yIwzYWJsQIHULKrhTrDXmQ815q5CUIhtkmVXe6ftMvojB5YTTaVUKC7lw3Kex0uT 9MFGs7bvnzoNF/XBK82XejRlDZ2IAcLTMNehq5Sp9vOyTag1MNh2tK6NrMXcx9DuoXZl nF2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Sc75jWdNzD1qCaBfOCvQyxisQbbgxmtfzu2nMqf1Jhk=; b=Kxqs8Yrqn33NSgxVVRJPHZKxptPqJpBb3mg9EKNBNqlWG9KygUSJj+MvQHAJKYJRWC RegPngK2A/VdXRoZXxrHT0vypXOuDaGTjVltO46MDMLN/D3cOMa6pOOln2TV/RdPhJFl osol3j2cB6aeWU9imJG8DYkVOG5SVwwjwoLhS2qQGzhHzXZtQefwYrPHfLgFlFhaANVP pfHEmTTKfGd19AA6YkCrvf0zWRkBljnQWjDTBt5WGu/JWocmkAZtqb3db7VJEtNA0y1i 1S6/JUPnZxVzBylgipFp17y1iFPfDQWclJIuNyO4qeYv5rYOH61DnM+N1eHIBpph/TSd OVzw==
X-Gm-Message-State: APjAAAVzi9p8gYW0PYXjMgI+yKa0rXrAkX9E8/r4x+uPvBEPFl5wqGQn 9M+h+LQiVGXEuoRwxoHOAl9CBQ==
X-Google-Smtp-Source: APXvYqxiqDVTCoxqbXrA1/vpxV/V3jghoBWSkWCHDB6eGW+k1UU8afHDklWGHGl401Aquoh4SD43HA==
X-Received: by 2002:ae9:ee11:: with SMTP id i17mr30349362qkg.333.1579131198266; Wed, 15 Jan 2020 15:33:18 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:c07e:acd:1cfa:abc7? ([2601:18b:300:36ee:c07e:acd:1cfa:abc7]) by smtp.gmail.com with ESMTPSA id o7sm9108559qkd.119.2020.01.15.15.33.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2020 15:33:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-CDB76DB4-CA01-4954-A551-1748AA8FDF16"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 15 Jan 2020 18:33:15 -0500
Message-Id: <84E7C4F0-8C4D-4F33-ABF8-63DF3553638A@fugue.com>
References: <CAH1iCippzARhk53A-tCyPvvQYKWNbvcorrxKORvqkEcfOriWfw@mail.gmail.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>
In-Reply-To: <CAH1iCippzARhk53A-tCyPvvQYKWNbvcorrxKORvqkEcfOriWfw@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (17E202)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/MiRFIquEZw4VntPeIT9nGY3MKYw>
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:33:21 -0000

I don’t think it makes sense to use web PKI to establish trust, no. But to validate a certificate?  Sure. DANE is another good option, also not useful for establishing trust. 

> On Jan 15, 2020, at 18:13, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> 
> 
> 
>> 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