An Architecture for DNS-Bound Client and Sender Identities
draft-ietf-dance-architecture-10

[Ballot discuss]
** Section 5.
5.  Protocol implementations
  For each protocol implementation, a specific usage document needs to
  be published.  In this document, the DANCE protocol requirements and
  usage needs to be specified (this is refered above as the "How to
  DANCE" document).  These documents should as a minimum contain the
  following sections:

I’m having trouble understanding the guidance in this section.

-- What is a protocol implementation?  What exactly is being implemented?

-- Who has to publish a “usage document”?  Where?

-- This text references to a “How to DANCE” document “above” as having requirements?  I am having trouble finding such a section in this document.

-- This text appears to be mandating the creation of an artifact under certain circumstances (see above questions on clarifying that).  Assuming this text is discussing future protocol work in the IETF, should an informational status document be providing such direction?

Note, the typo "refered".

[Ballot comment]
I support the DISCUSS position of Deb Cooley.

** Section 1.
  Attempting to use organizational PKI outside the organization can be
  challenging. 

What is an “organizational PKI”? 

** Section 2
  *DANCE protocol:* A DANCE protocol is protocol that has been taught
  to use DANE client mchanisms..

What does it mean to “teach” a protocol something?  Is this equivalent to any protocol that uses DANE client mechanisms?  If so, what precisely is a “DANE client mechanism”?  Can a reference be provided?

Note the typo of "mchanism".

** Section 2
  *User:* A client whose name consists of a user identity and a DNS
  owner name prefixed with a _user label.

Is there a reference that can be provided to formally define a “DNS owner name”?

** Section 3.1
  Client/server communication patterns imply a direct connection
  between an entity which provides a service (the server), and an
  entity which initiates a connection to the server, called a client.
  A secure implementation of this pattern includes a TLS-protected
  session directly between the client and the server.  A secure
  implementation may also include public key-based mutual
  authentication.

What is a “direct connection”? Are middleboxes on path permitted? 

** Section 3.1
  Extending DANE to include client identity allows the server to
  authenticate clients independent of the private PKI used to issue the
  client certificate. 

Consider if you want to introduce “DANE” with a set of references.

** Section 3.1
  In many cases the client is not a user specific device (like a laptop
  or smartphone), but rather an enterprise or residential device with a
  non-user specific name.
…
  When the client is a user device, then additional precautions may be
  necessary to avoid divulging personally identitiable information in
  the DNS.

Why could enterprise devices not have sensitive names?

Note the typo of "identitiable"

[Ballot comment]
Thank you for the effort put into this specification.

I have only minor editorial comments that could be addressed in the next revision:
- I couldn't clearly identify what was intended by the words /The extension.../.
- Please could you define both /DANE/ and /DANCE/ when first mentioned.
- /The Messaging-oriented/ - Check whether the capital 'M'is correct?
- It would be helpful to define /TLSA/ when first mentioned.
- The last two bullets in section 5 currently omit a trailing period.

Best wishes,
Gorry

[Ballot discuss]
I'm discussing two ideas promoted by this draft:  1. using DNS as a public directory for people (privacy issue), 2. The trade of trusting CAs vs trusting a DNS DANE entry. Is more secure than the other (security)?

Section 1, para 4, 5, and 7:  'require users and devices', does this draft target users (i.e. people)?  I've heard that it is only for 'devices', but yet Section 4.1.3 (TLS user auth for an LDAP query), Section 4.1.7 (domain users), 4.1.11 (SSH client), and any other place the draft uses the term 'users' points to this being for both devices and people.  Using DNS as a public directory for people public keys/certificates has massive privacy implications.

Section 3.1:  This architecture seems to be making a trade of 'trusting private CAs' to 'trust what is in a DNS DANE entry'.  These two mechanisms are basically the same from a trust perspective.  Either a server trusts a CA, or it trusts the certificate/pub key in a DNS entry.  I see no advantage here, and it impacts both privacy and interoperability.

Section 3.2:  Again, users?  people?  Using DNS as a public directory has massive privacy issues.

Section 3.3:  I normally think of S/MIME as being used by people, and out of band public key discovery mechanisms is, in fact, a public directory.

[Ballot comment]
Thanks to Magnus Nyström for their secdir review.

Have the dance drafts (this and the 2 protocol drafts) been vetted through the tls working group?

Section 1, para 5:  'chilling effect', seems a little extreme.  It is a barrier, but surely not 'chilling'.

Section 1, para 6:  I would argue that this is 'by design'.  Why would I trust another domain?  At least without understanding the rules by which they run their system.  If that trust exists, then there are cross certificates which can provide the extension of trust of the private CAs.

Section 4.1, para 1:  One can use otherName uid attributes, but those classically can't be trusted by the server unless one can map that uid to an entity that the server knows/trusts.  This technique does not solve the privacy issues.

Section 4.1.1: So, one has to know which client domains are allowed, how would one accomplish that?  While trusting private CAs and mutual authenticated TLS is too hard. 

Section 6.5, para 2:  indeed.  and it isn't discussed here. 

Section 6.5.1:  'revocation is performed by simple removing a DNS record'... How do the systems that cache DNS entries get this?

Section 6.5.2:  Let me understand this.  For this particular protocol to work a manufacturer has to sign up to support their devices... forever?  Replacing devices because a manufacturer has walked away is, interesting.  How many manufacturers are interested in 'continuously involved with the day to day operation of the device', especially IoT devices?

[Ballot comment]
Hi Ash, Shumon, Olle, and Michael,

Thank you for the effort put into this specification.

Please find some comments below:

# Document goals

It would be useful to add a mention about expected use/target of this document to the introduction.

You may also consider a forward citation to the appropriate section to highlight the requirements you are making for specification protocols.

# Agents

CURRENT:
  *Store-and-forward system:* A message handling system in-path between
  the sending agent and the receiving agent.

Not sure to which components listed in the section, the sending/receiving agents map to.

# Extension

CURRENT:
  The extension also allows an application to find an application
  identity and set up a secure communication channel directly. 

Which extension are we referring to here? Please make that clearer in the doc.

# References for the “many” existing protocols

CURRENT:
  Within many existing store-and-forward protocols, certificates may be
  transmitted within the signed message itself. 

Can we provide examples of these “many existing” protocols? Citing reference would suffice.

# constrained

CURRENT:
  Within IoT applications, we find that networks may be more
  constrained. 

Maybe cite draft-ietf-iotops-7228bis#section 2.1 for a definition of “constrained”.

# stale references

There are several references that points to IDs that were adopted or published as RFCs. You may consider refreshing these.

Cheers,
Med

The following Last Call announcement was sent out (ends 2025-12-19):

From: The IESG
To: IETF-Announce
CC: dance-chairs@ietf.org, dance@ietf.org, draft-ietf-dance-architecture@ietf.org, paul.wouters@aiven.io, wjhns1@hardakers.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (An Architecture for DNS-Bound Client and Sender Identities) to Informational RFC


The IESG has received a request from the DANE Authentication for Network
Clients Everywhere WG (dance) to consider the following document: - 'An
Architecture for DNS-Bound Client and Sender Identities'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This architecture document defines terminology, interaction, and
  authentication patterns, related to the use of DANE DNS records for
  TLS client and messaging peer identity, within the context of
  existing object security and TLS-based protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dance-architecture/



No IPR declarations have been submitted directly on this I-D.

# Document History

1. Does the working group (WG) consensus represent the strong
  concurrence of a few individuals, with others being silent, or did
  it reach broad agreement?

The WG was very active in the beginning and very much solidified
around the architecture in question.  As time went on, many of the
most active participants ended up dropping away due to job changes,
etc.  But the core architecture still remains solid and accepted today
(but it took a while to get the three WG documents, including this
one, to this point).

2. Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

Generally the WG all agreed on a rough direction and there wasn't any
strong controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

4. For protocol documents, are there existing implementations of the
contents of the document?

I believe so, but I can not point to any directly.  CIRA had certainly
started some.

5. Have a significant number of potential implementers indicated plans
to implement?

There has been some recent push by various groups, including DRIP proponents, to get this published as they want to make use of it.

# Additional Reviews

1. Do the contents of this document closely interact with technologies
in other IETF working groups or external organizations, and would it
therefore benefit from their review? Have those reviews occurred? If
yes, describe which reviews took place.

The DANCE WG and the TLS WG participants did work together and agreed on the overall approach (and specifically looked closely at the other documents that are more TLS protocol impacting).  I believe all necessary reviews have been done.

2. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

No formal review of these were required aside from consulting with the
TLS WG.

3. If the document contains a YANG module...

N/A

4. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Only the idnits tool was needed as there is no other formal language in it.  Or with non-ascii characters, which are in the acknowledgments.  One page is too long, but that's a generation issue.

# Document Shepherd Checks

1. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

2. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

There are no known current issues.  Past reviews were undertaken by
iotdir and secdir, but have been addressed.

3. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational for this document.  There are two associated DANCE
documents in the standards track, however.

4. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

To the best of my knowledge all authors are very aware of the IPR requirements.

5. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes (and only 4 authors)

6. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

The only nits that exist are bogus about references without usage (and
there is), or missing ID information.

7. Should any informative references be normative or vice-versa? See
the IESG Statement on Normative and Informative References.

No changes needed.

8. List any normative references that are not freely available to
anyone.

All normative references are RFCs.

# Document History

1. Does the working group (WG) consensus represent the strong
  concurrence of a few individuals, with others being silent, or did
  it reach broad agreement?

The WG was very active in the beginning and very much solidified
around the architecture in question.  As time went on, many of the
most active participants ended up dropping away due to job changes,
etc.  But the core architecture still remains solid and accepted today
(but it took a while to get the three WG documents, including this
one, to this point).

2. Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

Generally the WG all agreed on a rough direction and there wasn't any
strong controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

4. For protocol documents, are there existing implementations of the
contents of the document?

I believe so, but I can not point to any directly.  CIRA had certainly
started some.

5. Have a significant number of potential implementers indicated plans
to implement?

There has been some recent push by various groups, including DRIP proponents, to get this published as they want to make use of it.

# Additional Reviews

1. Do the contents of this document closely interact with technologies
in other IETF working groups or external organizations, and would it
therefore benefit from their review? Have those reviews occurred? If
yes, describe which reviews took place.

The DANCE WG and the TLS WG participants did work together and agreed on the overall approach (and specifically looked closely at the other documents that are more TLS protocol impacting).  I believe all necessary reviews have been done.

2. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

No formal review of these were required aside from consulting with the
TLS WG.

3. If the document contains a YANG module...

N/A

4. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Only the idnits tool was needed as there is no other formal language in it.  Or with non-ascii characters, which are in the acknowledgments.  One page is too long, but that's a generation issue.

# Document Shepherd Checks

1. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

2. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

There are no known current issues.  Past reviews were undertaken by
iotdir and secdir, but have been addressed.

3. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational for this document.  There are two associated DANCE
documents in the standards track, however.

4. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

To the best of my knowledge all authors are very aware of the IPR requirements.

5. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes (and only 4 authors)

6. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

The only nits that exist are bogus about references without usage (and
there is), or missing ID information.

7. Should any informative references be normative or vice-versa? See
the IESG Statement on Normative and Informative References.

No changes needed.

8. List any normative references that are not freely available to
anyone.

All normative references are RFCs.