Session Date/Time: 26 Jan 2023 15:00

DANCE

Summary

The DANCE Working Group met to discuss the status and direction of two key documents: the DANCE Template for application-specific DANCE requirements and the DANCE Architecture document. Key discussions revolved around the scope and content of the template, its publication strategy, and the refinement of the architecture document to focus on unique DANCE use cases rather than an exhaustive list. Several specific use cases were reviewed for inclusion or removal from the architecture document, and decisions were made regarding terminology management.

Key Discussion Points

DANCE Template Document:
- Purpose: Michael introduced the template (available in a GitHub repo, ietf-dance-dancing-template), explaining its intent to guide authors in creating application-specific DANCE documents. It aims to be an empty document with a table of contents posing questions (e.g., "who would whose zone would it go into?", "what is the TTL?", "DNSSEC requirements?", "why not use a straight TLS certificate from a CA?", "what goes in the certificate, what gets verified?", "DNS entry naming conventions").
- Analogy: The template structure was compared to a similar template used in the ROLL WG for detailing protocol usage requirements.
- Benefits: The template is expected to standardize DANCE implementations, pre-load security/transport/DNS operations review questions, and make answers to DANCE questions more obvious.
- Publication Strategy Debate:
  - Michael suggested adopting it as a Working Group document for official status and discoverability, even without intending to publish it as an RFC (to avoid "wasting ISG time on an empty document").
  - Some participants expressed a preference for it to be published, either as an appendix to the architecture document or as a standalone draft, to ensure findability and provide a stable reference for new protocol designers.
  - A concern was raised about the potential for an Internet Draft to expire if not published.
- Conclusion on Template: A sense of those present indicated that the decision on publishing the template (as an appendix or standalone RFC) should be postponed. However, it was agreed that the working group chairs should adopt it as a WG document to ensure its discoverability and management, allowing authors to clone the repo to bootstrap new application-specific DANCE documents.
DANCE Architecture Document:
- Scope Refinement: The chairs emphasized that the architecture document should not be an "inventory list" of all possible DANCE use cases but should focus on "interesting" use cases that highlight different DANCE usages, naming spaces, or communication setups. Application-specific details should move to separate DANCE documents following the template.
- Specific Use Cases Review:
  - OAuth2 (Issue #6): The current architecture document is strict about DNS names, which does not directly involve client identity as in OAuth2. Rick volunteered to investigate the general client domain name situation, which may encompass OAuth2. It was agreed that if no specific text demonstrating unique DANCE requirements for OAuth2 is provided by a volunteer, it would be removed from the architecture document.
  - DNS over TLS Authentication (Issue #7): This use case, potentially involving Dane client authentication for DNS privacy (as previously suggested by Bill Woodcock), was discussed. The question was whether it presented unique DANCE requirements compared to other client authentication scenarios.
  - SMTP (Issue #8): Victor Duchovny was noted as a proponent for DANCE client authentication in SMTP (MTA-to-MTA and client-to-server submission). It was agreed that a brief mention of SMTP's benefit from DANCE client authentication is sufficient for the architecture document, with detailed specifics reserved for a separate application-specific document.
  - X-ARF / MUD Signing (Issue #14): This use case involved using DNS to retrieve keys for signing MUD files, a non-TLS document signing scenario. As no author had stepped forward to elaborate on its unique architectural implications, and it differs from TLS-based DANE, it was proposed for removal.
- Terminology: The working group discussed the need for a terminology section. It was agreed that the architecture document should pull in relevant terminology from the other DANCE Working Group documents (e.g., the TLS-related drafts) and that further terms would be added based on review feedback.

Decisions and Action Items

DANCE Template:
- Decision: The decision on whether to publish the template as an RFC (either as an appendix to the architecture document or a standalone RFC) is postponed.
- Decision: The working group chairs will adopt the ietf-dance-dancing-template document as a Working Group document to ensure its discoverability and facilitate its use.
- Action Item: Michael to continue refining the template by brainstorming and adding core questions (e.g., DNS zone, TTL, DNSSEC, certificate content, naming).
DANCE Architecture Document:
- Decision: The architecture document will be refined to focus on DANCE use cases that present unique architectural considerations, moving exhaustive application-specific details to future template-based documents.
- Decision: OAuth2 (Issue #6) will be removed from the architecture document unless a volunteer steps forward with specific text demonstrating unique DANCE requirements.
- Action Item: Rick will investigate the general client domain name situation, which may inform future considerations for OAuth2.
- Decision: DNS over TLS Authentication (Issue #7) will be mentioned in the architecture document as a "future use case," and the associated ticket will remain in the backlog for future work.
- Decision: SMTP (Issue #8) will be briefly mentioned in the architecture document as a beneficial use case for DANCE client authentication, with specifics reserved for a separate document.
- Decision: The text regarding X-ARF / MUD signing (Issue #14) will be removed from the architecture document, and the issue will be kept as a backlog ticket for future work.
- Action Item: The chairs will ensure the architecture document incorporates terminology definitions from other DANCE Working Group documents.
- Action Item: The chairs will update the architecture document with the outcomes of these discussions and publish a new version.

Next Steps

IETF 116 Session: A one-hour DANCE Working Group session has been requested for IETF 116.
IETF 116 Agenda: The agenda for IETF 116 will include an update on the architecture document, progress on the requirements template, and potentially the initial stages of an application-specific DANCE document (e.g., based on LoRaWAN, SMTP, or other protocols).
Template Introduction: It is expected that the template document and its purpose will be re-introduced at IETF 116 to a potentially larger audience.
Document Progress: The goal is to have the architecture document ready for a Working Group Last Call around the time of IETF 116, ensuring all DANCE documents are progressing.
Community Input: Participants are encouraged to provide feedback and contribute to the template's questions and the architecture document's content.