Subject: [Dance] call for adoption for

From: Wes Hardaker <[email-masked]>
Date: Thu, 24 Feb 2022 16:08:09 -0800

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.

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.

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 didn't discuss where it should go forward.  A possible reason to not
adopt this document in DANCE is that you believe it should belong in TLS
instead.  Please indicate your preference if you respond to this call.

-- 
Wes Hardaker
USC/ISI

---

From: Shumon Huque <[email-masked]>
Date: Fri, 25 Feb 2022 08:20:15 -0500

> instead.  Please indicate your preference if you respond to this call.

I don't have a strong preference personally.

If there is a general sentiment (or requirement) that TLS extensions are to
be adopted and published through the TLS wg, that sounds fine to me (who
knows the answer to that?).

Otherwise, doing it in DANCE may make sense since it is designed to work
with the other draft (dane client auth) that will presumably be adopted
here.

Shumon.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Feb 2022 21:04:41 -0500 (EST)

> started a 3-week call for adoption today, ending just before IETF 113.

I am in favour of adoption.

> you'll commit to participating in discussions about it and helping

Willing to help with reviews.

> A possible reason to not

The TLS WG in general seems to not really care about DANE related TLS
things, so I think DANCE is the better of the two. But I'm okay with
either.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 27 Feb 2022 23:36:10 -0500

I favor adoption of draft-huque-tls-dane-clientid and it makes sense to
adopt
these in Dance, for the reasons that Paul stated about DANE related TLS
drafts.

tim

On Thu, Feb 24, 2022 at 7:08 PM Wes Hardaker <[email-masked]> wrote:

> Dance mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dance
>

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 28 Feb 2022 08:47:55 -0500

I support adoption as well.  I have read previous versions of the draft 
and will continue to review.

As with the dane-client draft, there should be a review from someone 
more knowledgeable about TLS than me, but if the TLS WG can’t/won’t 
adopt, the work should be done by DANCE.

Scott

On 24 Feb 2022, at 19:08, Wes Hardaker wrote:

> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdance&amp;data=04%7C01%7Cscott.rose%40nist.gov%7C346b67433f4a4040d3e508d9f7f2f015%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637813445055972368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=1G78KTw6VGqrWtY9VanyRg1xqbzy%2FAtk166y145YdOw%3D&amp;reserved=0

=================
Scott Rose, NIST/CTL
[email-masked]
ph: +1-301-975-8439
GVoice: +1-571-249-3671

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Feb 2022 09:23:27 -0500

> started a 3-week call for adoption today, ending just before IETF 113.

Good.

    > you'll commit to participating in discussions about it and helping

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Feb 2022 08:31:59 -0800

> I think coordinate could mean joint WGLC, and early TLS WG review.

Consider this a "verify on list" then :-)

The DANCE chairs will certainly need to coordinate with the TLS chairs to
ensure the necessary wide review if we adopt it.
-- 
Wes Hardaker
USC/ISI