Subject: Re: [Danish] Updated charter post BOF discussion

From: Roman Danyliw <[email-masked]>
Date: Wed, 1 Sep 2021 17:24:12 +0000

Hi!

Based on the feedback to this specific charter text and the general support during the DANISH BOF at IETF 111, I'm going to be formally begin the chartering process.

Unlike the BOF name of DANISH, the proposed WG will be DANCE (DANE Authentication for Network Clients Everywhere).  The 00-00 version of the charter will be the text below.  To avoid future confusion on the associated mailing list (and after consultation with the chairs), we're going to sunset the DANISH mailing list (danish@ietf) in favor of a new DANCE mailing list (dance@ietf).

Thanks for all of the discussion and coordination to date to get us to this point.

Regards,
Roman

> -----Original Message-----
> From: Danish <[email-masked]> On Behalf Of Wes Hardaker
> Sent: Thursday, August 19, 2021 3:38 PM
> To: [email-masked]
> Subject: [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:
> 
>     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
> 
> --
> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Sep 2021 04:10:47 -0400 (EDT)

> 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 have read the new charter, and it addresses all the concerns I had. I
am in favour of forming a WG. Thanks for the work on resolving my
issues.

Paul

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 2 Sep 2021 12:54:20 +0000

Hi!

As described below, a proposed DANCE WG has been created. See:

* WG entry in datatracker: <https://datatracker.ietf.org/wg/dance/about/>

* Mailing list address: <[email-masked]>
-- To subscribe: <https://www.ietf.org/mailman/listinfo/dance>
-- Archive: <https://mailarchive.ietf.org/arch/browse/dance/>

This charter will be up for initial review by the IESG at the upcoming telechat on Thursday, September 9, 2021.

I welcome those currently subscribed to this list (danish@ietf) to subscribe to this new WG mailing (dance@ietf).  We temporarily have the awkward situation of two lists (danish@ietf and dance@ietf) -- the price we are paying to prevent future confusion of the WG name not matching the list name.  If you'd like to express support or concerns with the charter up until it comes to the initial review by the IESG (next week on Thursday September 9), please use this list.  This will make it easier for the IESG/IAB to see all feedback in one place.  For other topics or starting September 9, please start moving all conversations to the this new dance@ietf list.  The upcoming IESG and IETF community discussions on the charter will be arriving there.  Eventually, the danish@ietf list will be frozen and kept as only an archive.

Regards,
Roman

> From: Danish <[email-masked]> On Behalf Of Roman Danyliw
> Sent: Wednesday, September 1, 2021 1:24 PM
> To: [email-masked]
> Cc: Wes Hardaker <[email-masked]>
> Subject: Re: [Danish] Updated charter post BOF discussion
> 
> Hi!
> 
> Based on the feedback to this specific charter text and the general support
> during the DANISH BOF at IETF 111, I'm going to be formally begin the
> chartering process.
> 
> Unlike the BOF name of DANISH, the proposed WG will be DANCE (DANE
> Authentication for Network Clients Everywhere).  The 00-00 version of the
> charter will be the text below.  To avoid future confusion on the associated
> mailing list (and after consultation with the chairs), we're going to sunset the
> DANISH mailing list (danish@ietf) in favor of a new DANCE mailing list
> (dance@ietf).
> 
> > 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:
> >
> > 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:
> >
> > 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.
> > 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:
> >