Re: [Danish] Updated charter post BOF discussion

["Rose, Scott W." <[e-mail]>]

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:

> 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
> [e-mail]
> 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
[e-mail]
ph: [phone]
GVoice: [phone]