DANCE

Virtual:
https://meetings.conf.meetecho.com/ietf114/?group=dance&short=&item=1

Notes: https://notes.ietf.org/notes-ietf-114-dance

Attendance: 62ish

DANCE agenda:

5m - Chairs Introduction (Joey and Wes)

• DANCE architecture was adopted
• Architecture document has a new editor (Ash -> Anthony Cook)

Updated Document awaiting chair approval.

20m - Current work items

• TLS Extension document
• DANCE protocol

• Architecture document

• DANE TLS Client Auth

• TLS Extension

TLS 1.2 vs 1.3 Differences where Client ID are placed

Viktor: Attempted to address this topic (during UTA WG meeting) via TLS
extension.
Not sure which WG this goes.
Wes: Could go in this WG
Martin T: Why support a defunct protocol (TLS1.2)?
Shumon: This should be greenfield, people should speak up
Martin: Some classes of servers just publish to the world. You can avoid
privacy leaks via TLS 1.2 renegotiation.
Shumon: This is general purpose, but have not really discussed.
Viktor: Clients with privacy concerns, are not nodes in the DNS tree.
TLS 1.2 here to stay for a while according to some. (mcr: and DTLS 1.3
upgrade is even harder)
Wes: appears to be (relatively strong) support for both TLS 1.2 and
1.3
Bob M: justification for 1.2 and not for greenfield.
Nick S: Auth happens in TLS handshake. Is a requirement ? if not a
requirement, look at export authenticators.
modifying existing 1.2 implementations may pose challenges. 1.3 model
has stronger security model guarantees
Shumon: Trying to reduce burden on applications.
Viktor: Do we need a "please solicit my certificate" needed for this
document. Suggests ugly hacks.
Wes: is there a use case?
Viktor: might be the only way to get into SMTP without modifying SMTP
itself
Shumon: are there any other non-SMTP cases/generalized?
Victor: "anytime that clients don't usually have certs" like SMTP-auth
(?)
When you request certificates from clients, some panic instead of
gracefully not sending a cert (if they don't have a cert available)
Ben K: Has some other client cert optional use cases besides SMTP
Michael: These may be big upgrades.
For Chairs: Viktor should write certificate soliticing extensions

15m - DANCE use case 1 - Jacques Latour (CIRA)

Working with DIACC and others on digital identity related stuff
starting by issuing verifiable credential to IoT device, issuer uses
TLSA record to keep track of issued credentials
TLSA records can be used to verify status (NXDOMAIN is revoked status)
for a specific IoT device (e.g. iotregistry(.)ca)
(nothing new up until now from DNSSEC/dance perspective)
ok, but how do you discover/trust issuer from verifier perspective
legal side exists, but no technical yet?
create new RR, register IoT device registry w/ a trust registry i.e.
iot.registry.ca._trustregistry.trustregistry.ca
alternative to blockchain? uses existing DNSSEC to anchor digital
identity to anchor to IANA root zone DNSSEC trust anchor
Paul H: Instead of IANA, could it be some other organization?
Jacques: Could be anyone
Viktor: Publish some use cases
John O: Why a new RR Type?
Jacques: To show which trust registry
Wes: Read his slides more carefully

15m - DANCE use case 2 - Bob Moskowitz (DRIP)

unmanned aircraft need 2-way comms
two possibilities: ESP or DTLS? ADS-B (for manned aircraft) not an
option for regulatory reasons
(slides 1-4)

Martin: QUIC does some of the multi homing things.
Bob: Potential but not heard discussed. Manned Aircraft will be DTLS

(slides 5-9)

Paul W: (no hats) We have Ways of storing chains of DNS records. Also
TLS extension for these chains.
Bob: Bandwidth on ground is decent, but how do we do the handoff between
UTMs
Wes: Questions on bandwidth using DANCE and DANE
Bob: Doing byte counts. Headers currently.
Viktor: no known TLS stacks support this? any known implementations
supporting raw public key?
Bob: issue under investigation, might be stepping into unfamiliar
territory, so seeking advice from dance community
Paul W: (someone) OpenSSL? has raw public keys working
Ben:

Wes: These use cases require additionals documents.

5m - Open mic

Relevant documents:

• draft-wilson-dance-architecture-02
• draft-ietf-dance-client-auth-00
• draft-ietf-dance-tls-clientid-00

How to DANCE:

general info: https://datatracker.ietf.org/wg/dance/about/
meeting materials:
https://datatracker.ietf.org/meeting/114/session/dance
mailing list: https://www.ietf.org/mailman/listinfo/dance