Subject: [Danish] Updated charter post BOF discussion

From: Wes Hardaker <[email-masked]>
Date: Thu, 19 Aug 2021 12:37:52 -0700

Folks,

We've (Ash, Shumon, Todd and I) have taken the notes from the discussion
to produce a new version of the charter that we hope addresses the
points raised during the IETF111 BOF.  I've created a new pull request
to Michael's repo here:

    https://github.com/mcr/danish-bof/pull/9

Please feel free to make any comments about the wording/etc as needed
(soon please).

Note that we did change the name to DANCE per general agreement in the
BOF chat, etc.  That brings some confusion, as people have pointed out,
but it's better to do so now if possible rather than later to remove the
more specific IoT component in the name.

Additionally, if you support the formation of this working group and
haven't spoken up in support of it yet, please do so now (even a +1 is
good and appreciated, but indicating you'll review/comment/implement is
of course better).

Full text:

# Charter proposal for an DANCE WG

- Name: DANE Authentication for Network Clients Everywhere (DANCE) [TBD: verify]
- Revision: 1.3.0

## Objective

The DANE Authentication for Network Clients Everywhere (DANCE) 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 root of trust for a
PKI, which can be then used for establishing trust in certified public
keys.

The DNS namespace, together with DNSSEC, forms the most widely-recognized
namespace and authenticated lookup mechanism on the Internet.
DANE builds on this authenticated lookup mechanism to enable public key-based
TLS authentication which is resilient to impersonation, but only
for TLS server identities.
However, DANE did not define authentication for TLS client identities.

<!-- defines a lookup mechanism for TLS -->
<!-- server identities and a published trust-path to their public key. -->

In response to the challenges related to ambiguity between identically
named identities issued by different CAs, application owners
frequently choose to onboard client identities to a single private PKI
with a limited CA set that is specific to that vertical.  This creates
a silo effect where different parts of large deployment can not
communicate.  Examples of where DANCE could be useful includes SMTP
transport client authentication, authentication of DNS authoritative
server to server zone file transfers over TLS, authentication to DNS
recursive servers, and Internet of Things (IoT) device identification.

## Scope of work

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

DANCE will define how DNS DANE records will represent client
identities for TLS connections.

DANCE will coordinate with the TLS working group to define any
required TLS protocol updates required to support client
authentication using DANE.

The DANCE scope of work will be initially limited to just TLS client
authentication.  Future work may include using client identifiers for
other tasks including object security, or authenticating to other
protocols.

## Deliverables:

* DANCE architecture and use cases (IoT, SMTP client,
  authentication to DNS services, ...) document (9 months)

* DANE client authentication and publication practices (current draft) (6 months)

* A TLS extension to indicate DANE identification capability and the
  client's DANE identity name (current draft) (6 months)

-- 
Wes Hardaker
USC/ISI

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Aug 2021 19:17:22 -0400

+1 on this working group.

tim

On Thu, Aug 19, 2021 at 3:38 PM Wes Hardaker <[email-masked]> wrote:

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

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 20 Aug 2021 07:55:16 -0400

I support the formation of the WG. I have read the drafts and supplied 
some minor wording comments to the authors.

Scott

On 19 Aug 2021, at 15:37, Wes Hardaker wrote:

> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdanish&amp;data=04%7C01%7Cscott.rose%40nist.gov%7Cb506b9121d6f445125d008d96348e1ab%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637649986940384886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=p6sQUSfNHAd9jJKq0dPmfQlMsUXFBiFe1lPMpmjDmdE%3D&amp;reserved=0

=================
Scott Rose, NIST/ITL
[email-masked]
ph: +1-301-975-8439
GVoice: +1-571-249-3671

---

From: Jacques Latour <[email-masked]>
Date: Fri, 20 Aug 2021 13:58:45 +0000

+1 looks good

> -----Original Message-----
> From: Danish <[email-masked]> On Behalf Of Wes Hardaker
> Sent: August 19, 2021 3:38 PM
> To: [email-masked]
> Subject: [EXT] [Danish] Updated charter post BOF discussion
> 
> 
> Folks,
> 
> We've (Ash, Shumon, Todd and I) have taken the notes from the discussion to
> produce a new version of the charter that we hope addresses the points raised
> during the IETF111 BOF.  I've created a new pull request to Michael's repo
> here:
> 
> BOF chat, etc.  That brings some confusion, as people have pointed out, but
> it's better to do so now if possible rather than later to remove the more
> specific IoT component in the name.
> 
> Additionally, if you support the formation of this working group and haven't
> spoken up in support of it yet, please do so now (even a +1 is good and
> appreciated, but indicating you'll review/comment/implement is of course
> better).
> 
> 
> 
> Full text:
> 
> The DANE Authentication for Network Clients Everywhere (DANCE) 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 root of trust for a PKI, which can be then used for
> establishing trust in certified public keys.
> 
> DANE builds on this authenticated lookup mechanism to enable public key-
> based TLS authentication which is resilient to impersonation, but only for TLS
> server identities.
> In response to the challenges related to ambiguity between identically named
> identities issued by different CAs, application owners frequently choose to
> onboard client identities to a single private PKI with a limited CA set that is
> specific to that vertical.  This creates a silo effect where different parts of large
> deployment can not communicate.  Examples of where DANCE could be useful
> includes SMTP transport client authentication, authentication of DNS
> authoritative server to server zone file transfers over TLS, authentication to
> DNS recursive servers, and Internet of Things (IoT) device identification.
> 
> ## Scope of work
> 
> DANCE will specify the TLS client authentication use cases and an architecture
> describing the primary components and interaction patterns.
> 
> DANCE will define how DNS DANE records will represent client identities for
> TLS connections.
> 
> DANCE will coordinate with the TLS working group to define any required TLS
> protocol updates required to support client authentication using DANE.
> 
> authentication.  Future work may include using client identifiers for other
> tasks including object security, or authenticating to other protocols.
> 
> ## Deliverables:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 23 Aug 2021 08:17:42 +0200

> 20 aug. 2021 kl. 13:55 skrev Rose, Scott W. <scott.rose=[email-masked]>:
> 

I have read the drafts and support the formation of the working group.
+1
/O

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 23 Aug 2021 10:09:31 +0200

> good and appreciated, but indicating you'll review/comment/implement is

We support the formation of the working group, and we will be implementing and globally deploying any client authentication standard that comes out of it.

                               -Bill