IETF Logo Mail Archive

Re: [Dance] call for adoption for

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 28 February 2022 14:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7473A10B4 for <dance@ietfa.amsl.com>; Mon, 28 Feb 2022 06:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 OlsrR2JqK1qS for <dance@ietfa.amsl.com>; Mon, 28 Feb 2022 06:23:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3DC3A10EB for <dance@ietf.org>; Mon, 28 Feb 2022 06:23:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DAF7F389C9 for <dance@ietf.org>; Mon, 28 Feb 2022 09:32:21 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id akEq00H_ATuD for <dance@ietf.org>; Mon, 28 Feb 2022 09:32:19 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C3011389BF for <dance@ietf.org>; Mon, 28 Feb 2022 09:32:19 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1646058739; bh=yF7VJ+qH0K6ztby3UENVF1+2XxbxuZtvDckfyqQ7e6k=; h=From:To:Subject:In-Reply-To:References:Date:From; b=4uwhheiuIfBNGi2k7EEgU9qbTLtQ7J1yxqMRT3SKv91MrGCnUxCIGo0vZljJxcgVS LEjeB9zhmH6ZBYv67E1vM0GIen3hhPoZs51gJZNRLSi5FOKeKJgH8LrKg4FbGko474 D5uH2tTtbyPJ2v53DZ6gep01fgJViumdQhxcgSr1PgTBMcm1CQRQeIDdGwgV3CJ6JH qFqwtWPyZM53QRQ+KM2tlNaHYEYvc/Lg7myUANmSfNZWtRP8S2ECcgEXdv5Dy+0di+ H0w8KuF9Vla0LlKIRvEHb1sQict9OoGvk9HomjehCGXx7nbr9jDVB+Pjdyoovr1/Sm cDmO+wAFBI71g==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 11F13CA for <dance@ietf.org>; Mon, 28 Feb 2022 09:23:27 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dance@ietf.org
In-Reply-To: <ybly21z3j12.fsf@w7.hardakers.net>
References: <ybly21z3j12.fsf@w7.hardakers.net>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 28 Feb 2022 09:23:27 -0500
Message-ID: <1112.1646058207@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/sM3r53pNfh0sfNLxrmLBmyusKyE>
Subject: Re: [Dance] call for adoption for
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 14:23:38 -0000

Wes Hardaker <wjhns1@hardakers.net> wrote:
    > During IETF 112 the DANCE participants indicated
    > draft-huque-tls-dane-clientid was potentially ready for adoption.  I
    > started a 3-week call for adoption today, ending just before IETF 113.

Good.

    > We'd like to hear support for those in favor of adoption, and whether
    > you'll commit to participating in discussions about it and helping
    > review the document.

Yes, I will review the document.
I am in full support of progressing the document.
I've just read it again, I guess that DTLS 1.3 is coming any minute now.
I guess this extension applies to TLS 1.2, and I wonder if it needs to.

I wonder if there is any desired interaction with TLS subcerts?
Would it make sense for an auxilary device doing SIP authentication with TLS
client certificates (or SMTP authentication) to have an identity delegated
from a primary device to do authentication with.

"client's domain name identity can be obtained from its certificate"
cf: draft-ietf-uta-rfc6125bis-04, presumably, we mean the dnsName SAN, and
not some DC= bits in the SN.

The document is miraculously short.
It probably needs a Privacy Considerations, which will be different for 1.2
vs 1.3.   I worry that there will be a lot of questions about how it is used,
which would be better addressed in [DANECLIENT], but might get litigated twice.

    > NOTE: it is unclear if this is the right working group to publish this
    > under, or if it should advance in the TLS working group instead as it
    > is an extension to TLS.  Though we discussed adopting it during 112, we

I thought we resolved this during chartering :-)
We said we'd coordinate, but the document deliverable is a deliverable for DANCE.
I think coordinate could mean joint WGLC, and early TLS WG review.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email