From nobody Thu Aug 19 12:38:01 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E13A19B7 for ; Thu, 19 Aug 2021 12:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdBM5DxuwATe for ; Thu, 19 Aug 2021 12:37:57 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD973A19B6 for ; Thu, 19 Aug 2021 12:37:57 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 8F7E02399B for ; Thu, 19 Aug 2021 12:37:52 -0700 (PDT) From: Wes Hardaker To: danish@ietf.org Date: Thu, 19 Aug 2021 12:37:52 -0700 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Danish] Updated charter post BOF discussion X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 19:37:59 -0000 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. 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 nobody Thu Aug 19 16:17:43 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086663A080C for ; Thu, 19 Aug 2021 16:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_5G3a794-Aw for ; Thu, 19 Aug 2021 16:17:36 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C6D3A0805 for ; Thu, 19 Aug 2021 16:17:36 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id i28so14160153ljm.7 for ; Thu, 19 Aug 2021 16:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rdwuUwnE8nJs4SZtEJDB0jzrnaHPlXvKo+s6GOO79vY=; b=TnDTkIcrcoWc+Zu8kvT93t8kHrgHbCUWH7+D8OFSfm9wRAsyPLuGfg1SWbqlm8E/vZ gqwwjWIQ9dlIVte48IDtJjM1NrEv88M50juarPlkjnmD7/EciNou0uZ3GLrA1kFuqAC8 TXPvi+dd+miyQT+Kjax1xs+BnJx4p9aX7QFWFgdTX6oy8jRDs3EgWp4Ns7B2QcUasKZ5 yHayx/f/ckiY2cw2ngUw4TdzmS7ezV9inmmaUVtQYVAmNaFniwk8UCCoKlBs0PUGaDqY IHcQjaLM5eFO5SROmtup99X11Git0EW/0Y1qyg/YZGzekorz4QbKfNL9PdtrL2HjijzL k8/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rdwuUwnE8nJs4SZtEJDB0jzrnaHPlXvKo+s6GOO79vY=; b=CmDmQTrrdTpAhoxqQ7JEVq2VOEjZ3949mwmKsEQocNBy1f63R+5jkXE6ZhJFBsvkVk rmdA+QYm6AbH5jahcSX4fAp6nEozmrXdep7ADgAmHl5TuwHoG28cosdvCZ9eoVp1/w8N s7bQMsBPYWlYsNu49ch7V4AoxOTzEJFsPjISuxSSpBNMreVGFtzywng+JFyIZb06HypE iRgemOYBu3qm86/29l8rx7LbSTmZ9GI5vdesU0Dsf1U5pLtVeRbuMfXF5KxUwWU4dNgr j7H6OGtaZBKWNJi8fP9Snjhx6DpQ1hh7LFOxyjgJKwHl3roQM3Sc9W/toE+TpIOVvg6z TFEA== X-Gm-Message-State: AOAM5300jy3wyoIP57Xlkxh6Liz11NSlca646dHPyNPBsW26vi5kMeg5 2h8tYMfBaWMqRsmhtaztxNhXYhEzaEQ+rFzoOOH0z6iiA/s= X-Google-Smtp-Source: ABdhPJzAZWyzTTan/1FLsjmoGTX6Rjb58gtHWTUXz68XMrTR1TUKLQGJUNd3ZVpWndukgQ8u4SzGXvxW3ZIXvMEAKGU= X-Received: by 2002:a05:651c:106f:: with SMTP id y15mr13836861ljm.309.1629415053718; Thu, 19 Aug 2021 16:17:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 19 Aug 2021 19:17:22 -0400 Message-ID: To: Wes Hardaker Cc: danish@ietf.org Content-Type: multipart/alternative; boundary="00000000000077fa8805c9f1c1e9" Archived-At: Subject: Re: [Danish] Updated charter post BOF discussion X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 23:17:42 -0000 --00000000000077fa8805c9f1c1e9 Content-Type: text/plain; charset="UTF-8" +1 on this working group. tim On Thu, Aug 19, 2021 at 3:38 PM 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. > > > > > 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 > --00000000000077fa8805c9f1c1e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+= 1 on this working group.=C2=A0

tim


On Thu, Aug 19, 2021 at 3:38 PM Wes Hardaker = <wjhns1@hardakers.net> wr= ote:

Folks,

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

=C2=A0 =C2=A0 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.=C2=A0 That brings some confusion, as people have pointed out= ,
but it's better to do so now if possible rather than later to remove th= e
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<= br> 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: ve= rify]
- Revision: 1.3.0

## Objective

The DANE Authentication for Network Clients Everywhere (DANCE) WG seeks to<= br> extend DANE to encompass TLS client authentication using certificates or Ra= w 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-bas= ed
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.=C2=A0 This creates=
a silo effect where different parts of large deployment can not
communicate.=C2=A0 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.=C2=A0 Future work may include using client identifiers for<= br> other tasks including object security, or authenticating to other
protocols.

## Deliverables:

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

* DANE client authentication and publication practices (current draft) (6 m= onths)

* A TLS extension to indicate DANE identification capability and the
=C2=A0 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
--00000000000077fa8805c9f1c1e9-- From nobody Fri Aug 20 04:55:30 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF653A24DC for ; Fri, 20 Aug 2021 04:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1E2pGMQPhTw for ; Fri, 20 Aug 2021 04:55:21 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2117.outbound.protection.outlook.com [40.107.91.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B972C3A24D9 for ; Fri, 20 Aug 2021 04:55:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WYYPqCyVcQ8xsAoSHZyFmws9wVA4CC+gqUhi6eCxGtZ2CmCM0nmy1YuK+tRZJYz219YkplXB9rwmj4E7yGgxfuJ4y2AEYlih0J2svaZVfMLhQVFX6e4sY3+/1yyuVpsemdxG6X2K+fmjTj3MMiI/lGe11vaW0/II4UjfjkJc2P7lhwil9T7l/EJy68Kr2/zQU95yOMTaL0MonzqW22SPCmZzegiYBp257qD5vxIXudb4MOK0e18M1L4L/dpw7qlb4eufgUq4vKVULEes2NCLgTHM95Uqm8ZhTSO2a4hGbxym5WwJc6utgsNjw1gALx/bAYWQXYegU33ItrjZIL3Nyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tr+oleqA7ABKnx+cy6R9odY4DwL0RPdlwHEOi/m2qGk=; b=KxHYgBVZ7SfLhj0T2Xl38AUtWiZMlCIIiIRwhVCNTwOlvy6kQHUYgJfMzjBCvsMoRem66DcBCdiHBEPl98wwNydT7m4FuQwEcFsUalC+NcUOMQ8IwhKvmhFgQO3VPIvGpAzH3I4eqPF9xilbVgGNGq65aj4V511f0Pi8TGX5G5LPL5VbKt8XL6qdlfa7le+tWfMYj7W6FwGRIcsCazTTNDrZ58265IL5bmV6Wov7+6m32PuL92MqOPmbMhjB4+vdR+VtKJHEeFwT4d5Z10E8hUk8KE2PrN4E74soIr0rDkPjkYyQknYaRv2fgtm7NKjcmUBG6v3Hzu2ucPgUTUs4tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 129.6.18.29) smtp.rcpttodomain=ietf.org smtp.mailfrom=nist.gov; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nist.gov; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tr+oleqA7ABKnx+cy6R9odY4DwL0RPdlwHEOi/m2qGk=; b=M+zK+/ie7P/zfoTpxun9zgaQNPma/iznwsRNSDy/1WT2iQN+WH2sBrsgqStk3WvQ+otTdfpcA1z4yYrEsQlgFmS3LrFR+k8GBFM1yF9kyOgg09LBSD+DmsWv8gHgQAeckztubsv5sS5Qvk1AOIRG/n45GWp233vGIVYZJ5HOo58= Received: from DM6PR09CA0031.namprd09.prod.outlook.com (2603:10b6:5:160::44) by BLAPR09MB6691.namprd09.prod.outlook.com (2603:10b6:208:2ab::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Fri, 20 Aug 2021 11:55:19 +0000 Received: from DM3GCC02FT001.eop-gcc02.prod.protection.outlook.com (2a01:111:f400:7d04::203) by DM6PR09CA0031.outlook.office365.com (2603:10b6:5:160::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Fri, 20 Aug 2021 11:55:19 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 129.6.18.29) smtp.mailfrom=nist.gov; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=nist.gov; Received-SPF: Pass (protection.outlook.com: domain of nist.gov designates 129.6.18.29 as permitted sender) receiver=protection.outlook.com; client-ip=129.6.18.29; helo=smtp1.nist.gov; Received: from smtp1.nist.gov (129.6.18.29) by DM3GCC02FT001.mail.protection.outlook.com (10.97.8.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Fri, 20 Aug 2021 11:55:18 +0000 Received: from [129.6.219.32] ([129.6.219.32]) by smtp1.nist.gov with Microsoft SMTPSVC(10.0.14393.4169); Fri, 20 Aug 2021 07:55:16 -0400 From: "Rose, Scott W." To: danish@ietf.org Date: Fri, 20 Aug 2021 07:55:16 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: <35D39AFF-F038-4B7D-B11D-DFCF9C496E11@nist.gov> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Aug 2021 11:55:16.0821 (UTC) FILETIME=[3E0CF050:01D795BA] X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 85c351ba-d288-4479-119f-08d963d1617c X-MS-TrafficTypeDiagnostic: BLAPR09MB6691: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2nDxB21H55o78cfA05h0Dee6DrEd2JNwuvEJP6W7gPlD+EaKqDC4JoXFqhHbXcTgR7aCrv8F3BD3qgcnFssOSckRu1dswgeYyaPzpO3+jdutETv1JLGDrka95+7/G9NRWA0CzjHL3jSi2NVhQv3kDsCViHNj8T09tNP6xnbLCJAauHnkjdRU3T/i421WQP+JznahJmHxPwNaXwcTiJQjnv8AA+y8ZR4XK5Q+TCuOfONTLVgEX8sTbRS4EkfLSDt5pJM6OcJaUsKaxoXR5PlXCfCrni8C6R2b488XeIqoi+DYuUCq6lFEsuOAnc1OZxNVjhybgnDvh7sQAP++rsM1DtDPkDITSyF8QcMIu5gACC6s+CZXFwk4vu9nYRJcuBMrzfHUy8O54cKCr6p9hZp0gGdedeuW1m3rSyPVfANdfPcmioXbqIYlAYS3DqIlc9To3AF4PzfVHKq7FCx4KFVuxqnYBbDFBCExnrMaRr188CjvwAnMtH7npoabhE8kAWr7+ZGuwD90W78ISJyffyO+jEp7vGYHYpYnpXUkQH9uGBpQEpA4Z+C2+nFdnhd/qO1TCsDFP/qnxQMZ520OWnhWUdhFjojNNHlSACs1ZXavwj8U/cHy4NVzV7h9mzOQbN+o7PF3XgcDF77D1W1/15FEM9OB6h6pq8dPepo/CwtYoGTnare9PHPKK/AG5R1hU3My7HIrOKRbhOMYpL7hpmUOwI2ANH2EgxyqoiZ4ILyF4bHHkZFTiW5apWAIhRYuOFmF9rBwAMwutVEU47VuXDm837sLagHYVFxp8UcU86nsPnU= X-Forefront-Antispam-Report: CIP:129.6.18.29; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:smtp1.nist.gov; PTR:smtp1.nist.gov; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(46966006)(36840700001)(6706004)(956004)(15650500001)(6916009)(2616005)(86362001)(36860700001)(53546011)(966005)(82310400003)(33656002)(8676002)(186003)(336012)(426003)(316002)(66574015)(26005)(83380400001)(2906002)(5660300002)(70206006)(478600001)(356005)(82740400003)(7636003)(7596003)(47076005)(36756003)(45080400002)(8936002); DIR:OUT; SFP:1102; X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2021 11:55:18.3911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85c351ba-d288-4479-119f-08d963d1617c X-MS-Exchange-CrossTenant-Id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=2ab5d82f-d8fa-4797-a93e-054655c61dec; Ip=[129.6.18.29]; Helo=[smtp1.nist.gov] X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TreatMessagesAsInternal-DM3GCC02FT001.eop-gcc02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6691 Archived-At: Subject: Re: [Danish] Updated charter post BOF discussion X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 11:55:28 -0000 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. > > > > > 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://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fdanish&data=3D04%7C01%7Cscott.rose= %40nist.gov%7Cb506b9121d6f445125d008d96348e1ab%7C2ab5d82fd8fa4797a93e0546= 55c61dec%7C1%7C0%7C637649986940384886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D= p6sQUSfNHAd9jJKq0dPmfQlMsUXFBiFe1lPMpmjDmdE%3D&reserved=3D0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose, NIST/ITL scott.rose@nist.gov ph: +1-301-975-8439 GVoice: +1-571-249-3671 From nobody Fri Aug 20 06:59:02 2021 Return-Path: X-Original-To: danish@ietfa.amsl.com Delivered-To: danish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975EF3A07D0 for ; Fri, 20 Aug 2021 06:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPg4ihJXInrO for ; Fri, 20 Aug 2021 06:58:54 -0700 (PDT) Received: from mx-relay04-hz10.hornetsecurity.com (mx-relay04-hz10.hornetsecurity.com [108.163.133.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960AE3A07C7 for ; Fri, 20 Aug 2021 06:58:54 -0700 (PDT) Received: from nat.crp.cira.ca ([192.228.22.11]) by mx-relay04-hz10.hornetsecurity.com; Fri, 20 Aug 2021 09:58:51 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.10; Fri, 20 Aug 2021 09:58:45 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::f81d:1300:91bd:144c]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::f81d:1300:91bd:144c%14]) with mapi id 15.01.2242.010; Fri, 20 Aug 2021 09:58:45 -0400 From: Jacques Latour To: Wes Hardaker , "danish@ietf.org" Thread-Topic: [EXT] [Danish] Updated charter post BOF discussion Thread-Index: AQHXlTHPoi9/uz7ygki0t9xnfy73c6t8bIGA Date: Fri, 20 Aug 2021 13:58:45 +0000 Message-ID: <5419a3bf1ff04a09bc67531a14a0f946@cira.ca> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=8286c47c-b7e1-40ca-96ef-df701b4bf269; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=0; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-08-20T13:58:26Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-cloud-security-sender: jacques.latour@cira.ca X-cloud-security-recipient: danish@ietf.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay04-hz10.hornetsecurity.com with 85D4713628C0 X-cloud-security-connect: nat.crp.cira.ca[192.228.22.11], TLS=1, IP=192.228.22.11 X-cloud-security-Digest: 1da2efce05433e66f6de7348cfee848f X-cloud-security: scantime:3.619 Archived-At: Subject: Re: [Danish] [EXT] Updated charter post BOF discussion X-BeenThere: danish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DANE AutheNtication for Iot Service Hardening List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 13:59:00 -0000 +1 looks good > -----Original Message----- > From: Danish On Behalf Of Wes Hardaker > Sent: August 19, 2021 3:38 PM > To: danish@ietf.org > Subject: [EXT] [Danish] Updated charter post BOF discussion >=20 >=20 > Folks, >=20 > 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 ra= ised > during the IETF111 BOF. I've created a new pull request to Michael's rep= o > here: >=20 > https://github.com/mcr/danish-bof/pull/9 >=20 > Please feel free to make any comments about the wording/etc as needed > (soon please). >=20 > 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, b= ut > it's better to do so now if possible rather than later to remove the more > specific IoT component in the name. >=20 > Additionally, if you support the formation of this working group and have= n'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). >=20 >=20 >=20 > Full text: >=20 > # Charter proposal for an DANCE WG >=20 > - Name: DANE Authentication for Network Clients Everywhere (DANCE) [TBD: > verify] > - Revision: 1.3.0 >=20 > ## Objective >=20 > 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). >=20 > ## Problem Statement >=20 > The process of establishing trust in public-key-authenticated identity ty= pically > involves the use of a Public Key Infrastructure (PKI), and a shared PKI r= oot of > trust between the parties exchanging public keys. A Certification Authori= ty > (CA) is one example of a root of trust for a PKI, which can be then used = for > establishing trust in certified public keys. >=20 > 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 fo= r TLS > server identities. > However, DANE did not define authentication for TLS client identities. >=20 > >