- Tuesday, 2023-11-06 -- 17:30 local -- 16:30 UTC
- Notes: Hafiz Farooq
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:
How to DANCE:
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
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
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
Commenter: Michael Richardson
- Agreement: Will be reviewed for further elaboration
Smallwer wording suggestions
Commenter: Michael Richardson
- Agreement: Will be updated
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
- 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
- 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
- Comment from Robert Moskowitz
- Agreement: This suggest will be dropped and leave it as is
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
- 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:
- 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
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)