# Meeting information   {#meeting-information}

*   Tuesday, 2023-11-06 -- 17:30 local -- 16:30 UTC
*   Notes: Hafiz Farooq

# DANCE agenda:   {#dance-agenda}

*   5m - Chairs Introduction (Wes and Joey)
*   25m - resolving LC comments (Wes and Joey)
*   20m - IOT authentication in AfNIC (Gaël Berthaud-Muller)
*   10m - future of DANCE / Open MIC (Wes and Joey)

# Relevant documents:   {#relevant-documents}

*   [draft-ietf-dance-architecture][1]
*   [draft-ietf-dance-client-auth][2]
*   [draft-ietf-dance-tls-clientid][3]

# How to DANCE:   {#how-to-dance}

*   general info: https://datatracker.ietf.org/wg/dance/about/
*   meeting materials:
    https://datatracker.ietf.org/meeting/interim-2023-dance-01/session/dance
*   mailing list: https://www.ietf.org/mailman/listinfo/dance

# Discussion and resolutions on the last call comments   {#discussion-and-resolutions-on-the-last-call-comments}

## Examples should be used (wildcard and DANE-TA)   {#examples-should-be-used-wildcard-and-dane-ta}

Commenter: Rick van Rein

*   Agreement: Volunteers needed to add examples

## Transport label encoding may not be needed   {#transport-label-encoding-may-not-be-needed}

Commenter: Michael Richardson

*   both TLS and DTLS are functionality dual usable
*   Agreement: Leave it as is

## Are there privacy concern because of client identity harvesting in DANCE   {#are-there-privacy-concern-because-of-client-identity-harvesting-in-dance}

Commenter: Robert Moskowitz

*   Do we need a better security consideration section description
*   Agreement: Will be updated

## WHy is there an exception that allows for SHOULD when use X.509 certification   {#why-is-there-an-exception-that-allows-for-should-when-use-x509-certification}

Commenter: Michael Richardson

*   Agreement: Will be reviewed for further elaboration

## Smallwer wording suggestions   {#smallwer-wording-suggestions}

Commenter: Michael Richardson

*   Agreement: Will be updated

## Checking regarding supported TLS version   {#checking-regarding-supported-tls-version}

*   We have reference to TLS 1.2, 1.3 and DTLS 1.3
*   We have reference to RFC8446
*   Agreement: A reference to RFC6066 is not needed (TLS extension),
    however use fuzzy wording

## Request for Calrity on ClientName limit/length definition   {#request-for-calrity-on-clientname-limitlength-definition}

*   Comment from Rick van Reinn and Michael Richardson
*   Agreement: Mark Andrew highlighted longer length possible >255, it
    will be reviewed by the Shephard about TLS length.

## Use Stiffer Requirement to improve interoperability and reduce code complexity   {#use-stiffer-requirement-to-improve-interoperability-and-reduce-code-complexity}

*   Comment from Rick van Reinn and Michael Richardson
*   Agreement: Due to the "MIXED" scenarios, SHOULD will be used instead
    of MUST.

## Draft Should say what RR content it expects   {#draft-should-say-what-rr-content-it-expects}

*   Comment from Robert Moskowitz
*   Agreement: This suggest will be dropped and leave it as is

## Use case for mixed environments in terms of CAs   {#use-case-for-mixed-environments-in-terms-of-cas}

*   Comment from Rick van Reinn
*   Agreement: Not clear what is meant by Mixed Environments, so will be
    left as is

*(18:05 COMMENT Discussion Ended)*

# IOT authentication and domain joining in LoRaWan in AfNIC   {#iot-authentication-and-domain-joining-in-lorawan-in-afnic}

*   Doamin Joinin procedure
*   How to apply DANE/DANCE to LoRa join procedure
*   Authentication: Construction the JoinRequest
*   Authentication: Validating the JoinRequest, first extract DeviceEUI,
    query TLSA and verify
*   Authentication: Constructing the JoinAccept, by adding DnssecChain
    (variable length)
*   Authentication: Constructing the DNSSEC Chain based on RFC9102.
    Avoid CNAME to reduce the Chain size. Use a intermediary trust
    anchor
*   Authentication: Enocding the DNSSEC Chain using CBOR
    (draft-lenders-dns-cbor-04). Compress ECDSA keys in DNSKEY and TLSA
    RRs (64b to 33bytes)
*   Authentication: Enocding the DNSSEC Chain (CDDL)
*   Authentication: JoinAccept Fregmentation Process due to large
    payload size. Next frament is requested by the device.
*   Authentication: Validating the JoinAccept using the shared trust
    anchor as starting point. Validates TLSA/JoinEUI.
*   Evalution (in progress) - nearly 30s with high date rates
    (200bytes/packet)

## Q&A:   {#qa}

*   Robert: Packet size issue highlighted
*   Wes: Is it deployed live, how long it will take. Answer: It is work
    still in POC.
*   Wes: You are only using single Algorithm, which is a concern.
    Answer: It's due to constraint on the device
*   Shumon: Which CBOR compression is being used. Answer: Not sure, plan
    to engage DNS people for review
*   Shumon: Will discuss later on one question

# Closing Discussion about the future of DANCE   {#closing-discussion-about-the-future-of-dance}

Do we have any future comments/works after the finalization of this  
work. Should we propose more drafts and work? Are there participants  
that are willing and have the energy to bring more work to DANCE?

Yaroslav: Identity provisioning should be studied by this working group.

Wes: There are many proposals with BoF related to identity management.

Jacques Latour: DANCE should be used for digital credentilas, may be
studied in the group.

Robert: Why DANCE is more focused and narrow scoped and should
discovered for TLSA. Wes: If you can send some documents to explain.

*(18:32 Meeting Finished)*



[1]: https://datatracker.ietf.org/doc/draft-ietf-dance-architecture
[2]: https://datatracker.ietf.org/doc/draft-ietf-dance-client-auth
[3]: https://datatracker.ietf.org/doc/draft-ietf-dance-tls-clientid