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