Re: [Danish] revised charter text from Tuesday morning
Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 27 June 2021 18:05 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: danish@ietfa.amsl.com
Delivered-To: danish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE463A10A2 for <danish@ietfa.amsl.com>; Sun, 27 Jun 2021 11:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 vFcZi7rDL2TE for <danish@ietfa.amsl.com>; Sun, 27 Jun 2021 11:05:21 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122373A10A0 for <danish@ietf.org>; Sun, 27 Jun 2021 11:05:20 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id AD910CDF07; Sun, 27 Jun 2021 14:05:19 -0400 (EDT)
Date: Sun, 27 Jun 2021 14:05:19 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: danish@ietf.org
Message-ID: <YNi93ysGwrxLTenF@straasha.imrryr.org>
Reply-To: danish@ietf.org
References: <17670.1624372831@localhost> <2F9979ED-0400-4E71-A7D1-F49919004C6F@dukhovni.org> <12180.1624808820@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <12180.1624808820@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/ZYb5fdb490DRGTNfmr0UMVi3cHI>
Subject: Re: [Danish] revised charter text from Tuesday morning
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DANE AutheNtication for Iot Service Hardening <danish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/danish>, <mailto:danish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/danish/>
List-Post: <mailto:danish@ietf.org>
List-Help: <mailto:danish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/danish>, <mailto:danish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jun 2021 18:05:23 -0000
On Sun, Jun 27, 2021 at 11:47:00AM -0400, Michael Richardson wrote: > I don't think that my text conflates anything, but let me ask you: > > > A CA's public key (or the associated certificate) can be a trust-anchor > > in a PKI, but is not in itself a PKI. > > *can* implies that there is an alternative. What is that alternative? A CA's public key can be just a CA key without being a trust-anchor. And my larger point was that even a trust-anchor is not a PKI, it is just a (trusted by some) public key. > What in practice, does not conflating mean? Conflating means that you're calling a CA certificate a PKI, but it is just a public key container. > > DNS is the largest (only) Internet-wide federated namespace. DNSSEC > > provides end-to-end integrity for DNS, obviating the need to trust > > intermediate caches. DNSSEC also makes it possible to securely publish > > the public keys or certificates of (DNS) named entities. > > If you are suggesting changes to the text, please just make them? > I'm not in disagreement with you, and I'm lost as to what your point is. My point is that the present text is misuses terminology to the point of confusion and failure to make the intended point. > > DNS is not a discovery mechanism. DANE makes it possible to securely > > Given a name, I can discover a key. No, discovery is something else, it is a one-time activity. You discover something, and then it is known (indefinitely). DNS is not discovery, it is lookup, and the data in DNS is used for a short time (minutes to hours) and then discarded. There are discovery mechnisms that do use data from DNS, the main one I see is publishing the MSA/IMAP server names for a domain, which the MUA caches indefinitely (and ideally asks the user to initially confirm), but DNS on the whole *not* a discovery system. In the rare cases where the DNS is (ab)used for "discovery" (use of data long past its TTL) there needs to be a very good reason as to why that's a reasonable thing to do. [ One time autoconfiguration of an MUAs from the user's email address is one of the few reasonable exceptions to the general rule that one should not use DNS data past its use-by date. ] > > Ambiguity is not relevant, and fails to capture the key issues. > > please send suggested changes they would be most welcome I thought I did. The discussion needs to be about the need for global names and trusting the authoritative source of data or their rightful agent. The WebPKI is entirely unsuitable for client identity, since the CA/B forum CAs cannot notarise what they cannot observe (can't connect to clients to perform ACME challenges). It is also not reasonable to accept attestations about clients used in granting access to sensitive resources from any CA on the planet. Once the discussion shifts away from "ambiguity", to global naming and trust, one can finally begin to ask meaningful questions about the long-term stability of names, the durability of trust, whether in fact one wants to do "discovery" and then issue local names and keys to the discovered entity, or whether the interaction is short-term and with many similar peers, making vendor-managed naming attractive. The hope was that the posted critique would be a basis for improving the text in a way that also satisfies goals I may have missed, or mistakes I may have made. IoT is not a space I've thought much about. -- Viktor
- [Danish] revised charter text from Tuesday morning Michael Richardson
- Re: [Danish] revised charter text from Tuesday mo… Wes Hardaker
- Re: [Danish] revised charter text from Tuesday mo… Ash Wilson
- Re: [Danish] revised charter text from Tuesday mo… Shumon Huque
- Re: [Danish] revised charter text from Tuesday mo… Viktor Dukhovni
- Re: [Danish] revised charter text from Tuesday mo… Michael Richardson
- Re: [Danish] revised charter text from Tuesday mo… Viktor Dukhovni
- Re: [Danish] revised charter text from Tuesday mo… Wes Hardaker