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

+1 looks good

> -----Original Message-----
> From: Danish <danish-bounces@ietf.org> On Behalf Of Wes Hardaker
> Sent: August 19, 2021 3:38 PM
> To: danish@ietf.org
> 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:
> 
>     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
> Danish@ietf.org
> https://www.ietf.org/mailman/listinfo/danish