Markdown Version | Session Recording
Session Date/Time: 06 Nov 2023 16:30
Dance
Summary
The Dance working group meeting focused on resolving outstanding last call comments on two documents: draft-ietf-dance-client-auth and draft-ietf-dance-tls-client-id. Discussions covered various technical issues including example generation, TLS version support, privacy considerations, client ID definitions, and interoperability. A presentation on using DANE and Dance for IoT device authentication was given by Gayle from Afni. The meeting concluded with a discussion about the future of the Dance working group and potential new work areas.
Key Discussion Points
- Example Generation (draft-ietf-dance-client-auth): Rick suggested adding examples for domain names and wildcard DANE TA. Discussion centered on clarifying what Rick meant by the domain name example and finding volunteers to write examples for both cases.
- Transport Label Encoding (draft-ietf-dance-client-auth): Michael Richardson questioned the need for transport label encoding. It was clarified that the document provides examples but is not prescriptive, allowing applications to define different formats in application profiles.
- Privacy Concerns (draft-ietf-dance-client-auth): Bob Moskowitz raised concerns about client identity harvesting. Discussion emphasized the need for a brief security iteration description to address potential information leaks.
- X.509 Certificate Usage (draft-ietf-dance-client-auth): Michael Richardson suggested changing a "should" to a "must" regarding the use of an X.509 certificate. Explanation clarified that client authentication can occur in different modes, and that the client ID extension is only required if the domain name identity can not be extracted from the certificate.
- Supported TLS Version (draft-ietf-dance-tls-client-id): Discussions centered on whether to reference 6066. It was discussed if wording could be altered to anticipate future TLS versions.
- Client Name Definition (draft-ietf-dance-tls-client-id): Discussions focused on length limits on the client name and different name types. How to address empty client ID extensions and prevent an alert.
- IoT Device Authentication Presentation: Gayle presented work from Afni on using DANE and Dance to authenticate IoT devices using LoraWan. Discussed how they are using the IETF draft for DNS messages. They are fragmenting everything for the very small frames.
- Future of the Dance Working Group: Discussions took place about the future of the working group assuming these last two documents are published. Suggestion was made to work on identity provisioning, especially for IOT.
Decisions and Action Items
- Example Generation: Plan to add examples if a volunteer comes forward; otherwise, the document will proceed without them.
- Privacy Concerns: Bob Moskowitz will suggest text for the document to address client identity harvesting.
- X.509 Certificate Usage: Shuman will review the document and add some text to clarify why client ID extensions are not required in all cases.
- Supported TLS Version: Update the text to say "and future TLS versions as far as we are aware at the moment."
- Client Name Definition: Mark and Shuman will collaborate on the correct length value for 255. They will consult with Ecker to verify the TLS presentation format.
- Future of the Dance Working Group: Continue discussion on the mailing list to assess interest and potential new work items. Ursula will draft a description of identity provisioning as related to dance and put it on the mailing list.
Next Steps
- Address action items related to last call comments.
- Submit updated drafts to the AESG after mailing list confirmation.
- Continue the mailing list discussion regarding the future of the working group and potential new charter items.