Room: Richmond 4 (West Wing 1st floor)
Virtual:
https://wws.conf.meetecho.com/conference/?group=dance&short=dance&item=1
Notes: Jim Fenton, Tim Wicinski
10m - WG Introduction (Wes and Joey)
15m - Current work items
Rick van Rein:
Brendan Moran: rfc6920 concerning hashes
Paul Wouters: (author of 6920) are more complications mapping to DNS
Jim Fenton: jumped into details, would like use cases.
Shumon Huque: going next with slides!
Michael Richardson: other docs don't ref arch document.
Wes: great discussion for the mailing list
Ben Schwartz: can be creating lots of waste if not solved properly
Rick van Rein: useful for example
LoRaWan use case
20m - Open MIC
time remaining - Q&A
Meeting began with inspiring DANCE music (and chairs swaying to it).
Joey began with introducing the NOTE WELL and code of conduct and
reminding everyone to scan the QR code or equivalent.
Three active drafts to consider:
dance-architecture, needs more work
dane-clientid, in 3 week wg last call
dane-client-cert, in 3 week wg last call
Mailing list activity slow, please "speak" up
Architecture-xx "is a mess"
Rick von Rein: It doesn't speak enough about end users. We might be able
to help with that.
DNS trees -- DNS gurus suggest a more hierarchical namespace, e.g. ENUM,
PTR
Privacy -- can't use URI to index DNS. Maybe a hash instead.
Rick: maybe have a root CA representing users
Brendan: See RFC 6920
Paul Wouters: consider case insensitivity of DNS
reorganize client-cert-09 into a DANCE impl requirement doc?
Need 1 document each for _service and _device.
Other patterns to code identity into DNS name?
Code somewhere? Maybe next hackathon should look into some libraries.
Also need OpenSSL, etc.
Jim Fenton: Use cases should describe problem
Michael Richardson: Other documents don't reference the arch document.
Intentional or not? Probsbly non-normative reference because arch
documents are normally informational.
Wes: Not sure if arch document is PS or informational (it is
informational). These are good last call comments.
Michael: Should manufacturer necessarily own a device's zone, or can it
be the owner/operator? Different trust models. Probably browsers will
not be in the browser-maker's zone.
Wes: Consider what of these require changes to DNS
MR: Unlikely that there are changes on the wire, but deployment may
differ. Expect security feedback.
Olle: Do we allow concurrent DNS in two zones, or how do we transfer
ownership?
Benjamin Schwartz: If we don't have a solution to this, DANCE may create
a lot of e-waste because of limitations in device authentication.
Consider what happens if manufacturer goes away.
Chairs: These are great mailing list discussion topics!
Olle: Have github repo for arch document, encourage Shimon to move other
documents to same repo.
There is one implementation -- French
Arch document describes applications more than use cases.
A little different from e.g., SIP so may be a little difficult to
describe
Flat namespace comment: don't necessarily agree.
Wes: Do current docs discuss transfer of ownership? (answer: No)
Email-like record name formats (like SIP): Docs aren't prescriptive
about record name formats.
Paul Wouters: Not intended as a privacy mechanism.
Not sure we should be using it in that way.
Rick: Would like a doman name example
Use of wildcards may belong in the protocol document
Only one half of an SRV record: true. Should discuss record name format
Viktor Dukhovni: Maybe have another tls extension, haven't progressed
that. Still interest in that?
MR and Shimon just discussed TLS extension to solicit certificate from
server. Planning to write that. Didn't make it for IETF 115 though.
That's more general than DANCE, so handle that here or in TLS wg, etc?
Another way to do DANE client auth at application layer (rather than
directly in TLS, and then maybe bind back to TLS)? No appetite for that
seen yet. Each application would have to implement it at the auth layer
then.
Viktor: If we want to authenticate email users to their submission
service, we might need that and use as a SASL mechanism.
very low bandwidth - RF space and IP spaces
Network keys and application keys. AES 128 bit. Network key at
manufacture. Needed for onboarding
LoRa 1 euro/year. Buying a cert not economical. Can't use LetsEncrypt
because it's not hierarchical.
DANCE allows federated CAs, implementation presented in IETF 113
Shimon did a go library for DANE TLSA authentiation
Proof of concept for client authentication
IETF 115 hackathon did AAA server authentication for IoI using DNSSEC
auth chain
Birds and bees talk about how new protocols are made...
Looking for (very BOF-like) commitments:
Shimon: reminded that Robert Moskowitz has questions, did we answer
them? Do we need a new DANE usage mode? Do we need to define a new DANE
selector for CBOR?
Viktor: There are related selectors (binary blob), could make that
clearer. Ic CBOR outside TLS, question is moot. Haven't seen CBOR use
TLS certs yet.
Rick: Has already implemented (?), but eager to rip that out.
Noted that IETF isn't an operator organization
MR: interim topics? Need deadlines earlier than March, interims help
motivate that. Suggest 2 virtual interims before IETF 116.
Wes: Probably January for an interim.
Topics TBD on list.
Adjourned 1630