Subject: [Danish] revised charter text from Tuesday morning

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jun 2021 10:40:31 -0400

Hi, Wes, Roman and I got together for 30 minutes to go through the changes
using github.

Here is the history of our work:
  https://github.com/mcr/danish-bof/commits/main/charter.md

Read it in markdown:    https://github.com/mcr/danish-bof/blob/main/charter.md

Please review this in the next week and a half and propose text either on
github, or on the ML.
After changing "message" security to object security, we then moved all of
the object security stuff into a recharter, i.e. deleted it from the initial charter.

{Note that we speak about device identity at the end, because one pattern is
one device (a client) speaking to another device (a server).}

Here is the final text:

# Charter proposal for an DANISH WG

- Name: DANE AutheNtication for Iot Service Hardening
- Revision: 1.2.0

## Objective

The DANE AutheNtication for Iot Service Hardening (DANISH) WG seeks to
extend DANE to encompass TLS client authentication using certificates or Raw Public Keys (RPK).

## Problem Statement

The process of establishing trust in public-key-authenticated identity
typically involves the use of a Public Key Infrastructure (PKI), and a
shared PKI root of trust between the parties exchanging public keys. A
Certification Authority (CA) is one example of a PKI which can be used for
establishing trust in public keys.

The DNS namespace, together with DNSSEC, forms the most widely-recognized
namespace and authenticated discovery mechanism on the Internet.
DANE builds on this authenticated discovery mechanism to enable public key-based
TLS authentication which is resilient to impersonation, but only for TLS
server identities.
What DANE did not define is how services can authenticate connecting clients.

In response to the challenges related to ambiguity between client identities issued
by different CAs, application owners frequently choose to onboard IoT devices
to a single private CA specific to that vertical.
This creates a silo effect where different parts of large deployment can not
communicate.  For instance the heating/cooling system of a building
wishing to turn lights off to reduce room temperatures can not
authenticate to the lighting control system.

## Scope of work

DANISH will specify the TLS client authentication use case and an
architecture describing the primary components and interaction patterns.

DANISH will establish usage conventions for DANE DNS records to represent
client identity for TLS connections.

DANISH will work with the TLS working group to define any required
TLS v1.3 protocol updates required to support client authentication using
DANE.

Future work may include using client identifiers for other tasks including object security, or authenticating to other protocol services.
The DANISH working group will take care to ensure a
potential path for interoperability, enabling these potential future directions.

## Deliverables:

* DANISH architecture document (9 months)

* DANE for device certificates (current draft) (6 months)

* DANE for TLS client authentication (current draft) (6 months)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Jun 2021 07:48:52 -0700

> Please review this in the next week and a half and propose text either on

And specifically:

1. Does anyone object to this proposed path.  We believe there is likely
   consensus on this narrowed scope and that it's unlikely a wider scope
   at this will achieve consensus (but the charter notes at the bottom
   that other future items may be possible).

2. Who is willing to:

   - contribute in mailing list discussions
   - edit drafts
   - review drafts

   Please do respond to these messages to indicate your willingness to
   help if DANISH is approved as a WG.

-- 
Wes Hardaker
USC/ISI

---

From: Ash Wilson <[email-masked]>
Date: Fri, 25 Jun 2021 10:11:28 -0700

Hi Team,

I have no objection to the charter.

I commit to contributing in the following ways:
- Mailing list participation
- Draft development, editing, review
- Technical validation

On Tue, Jun 22, 2021 at 7:49 AM Wes Hardaker <[email-masked]> wrote:

> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish
>

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 25 Jun 2021 21:50:11 -0400

Charter looks okay to me.

I'm willing to contribute, review, and edit drafts.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Jun 2021 15:08:19 -0400

> On 22 Jun 2021, at 10:40 am, Michael Richardson <[email-masked]> wrote:
> 

I don't think it is correct to conflate a CA with a PKI.  A PKI is an ecosystem,
that consists of some mixture of:

  * Relying parties
  * Key holders
  * Certification authorities
  * Registration Authorities
  * CRL distribution services
  * OCSP services
  * CT logs?
  * ...

A CA's public key (or the associated certificate) can be a trust-anchor in a PKI,
but is not in itself a PKI.

> namespace and authenticated discovery mechanism on the Internet.

This rather lacks context and looks poorly framed to me.  Why are we suddenly
talking about "discovery".  DNS is a distributed directly (lookup) service, it
is not a "discovery" mechanism, even if some "discovery" mechanisms happen to
leverage DNS at some point.

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.

> TLS authentication which is resilient to impersonation, but only for TLS

DNS is not a discovery mechanism.  DANE makes it possible to securely look up
the public key or certificate (in full or a digest) associated with a (DNS)
named entity.  In the case of TLS, DANE presently only defines naming for
server endpoints.

> What DANE did not define is how services can authenticate connecting clients.

There is presently no standard definition of client identity names, nor how a
client would communicate its DNS name to a server in a given protocol.

> to a single private CA specific to that vertical.

All mention of "ambiguity" needs to go.  It is misleading and not the real issue
at hand.  The problem is not "ambiguity".  The relevant concerns are:

  * Need for global names.  If the relying party is not also the owner/operator
    of a private PKI, but rather relies on a global PKI, then of course the
    names being authenticated need to be global (e.g. DNS names).

  * Need to scope trust.  In many applications it is not acceptable to trust
    client identities issued by all the various CAs of the WebPKI.

Ambiguity is not relevant, and fails to capture the key issues.

-- 
	Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 27 Jun 2021 11:47:00 -0400

Viktor Dukhovni <[email-masked]> wrote:
    >> Certification Authority (CA) is one example of a PKI which can be used
    >> for establishing trust in public keys.

    > I don't think it is correct to conflate a CA with a PKI.  A PKI is an
    > ecosystem, that consists of some mixture of:

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?
What in practice, does not conflating mean?

    > 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.

    >> DANE builds on this authenticated discovery mechanism to enable public
    >> key-based TLS authentication which is resilient to impersonation, but
    >> only for TLS server identities.

    > DNS is not a discovery mechanism.  DANE makes it possible to securely

Given a name, I can discovery a key.

    > Ambiguity is not relevant, and fails to capture the key issues.

please send suggested changes they would be most welcome

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Jun 2021 14:05:19 -0400

On Sun, Jun 27, 2021 at 11:47:00AM -0400, Michael Richardson wrote:

> *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.

> 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.

> 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. ]

> 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