Skip to main content

Minutes IETF112: dance
minutes-112-dance-00

Meeting Minutes DANE Authentication for Network Clients Everywhere (dance) WG
Title Minutes IETF112: dance
State Active
Other versions markdown
Last updated 2021-11-23

minutes-112-dance-00

DANCE agenda:

  • Chairs Introduction - 10m

Note Well Note takers: Tim Wicinski with tale backup

  • Use case presentations - 40m
    • TLSA use case for DNS - Bill Woodcock - 10m
    • (https://datatracker.ietf.org/meeting/112/materials/slides-112-dance-use-cases-for-dane-and-bidirectional-tls-authentication-in-the-dns-00)

Viktor Dukhovni: using DANE TLSA for ongoing maint

dkg: Didn't understand "maintenance". Please clarify.

VD: folks publish TLSA and don't keep correct.

dkg: Use Cases. Not convinced client auth is required. Think on non-client authenication. Why is this "the" Use Case

Wes: Intent isn't really to establish this as "the" Use Case but one of several to be thinking about

BW: blinded certs not tied to identities.

(From Jabber: dkg: is it a design goal here to include role authentication and blinded certs? Wes: it's a design goal to build a flexible framework that can enable multiple future forward paths with the resulting technology. It's not within scope to select individual ones and DANCE outputs would map to them now.)

<pre>- Device-to-cloud - Ash Wilson - 10m - https://datatracker.ietf.org/meeting/112/materials/slides-112-dance-dance-https-00.pdf </pre>

Ben Schwartz: client ship complete DANE cert chain?

WH: So you mean sending all DNSKEYs and RRSIGS up to the root?

BS: Client should not have to do any network to validate. Should not cache anything

VD: Agree with Ben but maybe optional

Shumon Huque: TLS chain extension can do this, configure to go the other way. (RFC 9102)

<pre>- EAP-TLS use case - Ash Wilson - 10m - https://datatracker.ietf.org/meeting/112/materials/slides-112-dance-dance-eap-tls-00.pdf </pre>

dkg: How client selecting which identity to present to the network?

AW: For many IoT devices they'll only be able to have one identity to present. Will have to think more for the generalized user case.

(Ben, in Jabber: I think IoT is not a good use case for DANCE until we have a "re-provisioning" system so the owner can change the name of the device.)

Viktor: skeptical of this use case (edit note: which one? What is "this" [chair: I believe he meant EAP/clients at all])

  • Architecture document presentations - Ash Wilson - 30m
    • https://www.ietf.org/archive/id/draft-wilson-dance-architecture-00.txt
    • https://datatracker.ietf.org/meeting/112/materials/slides-112-dance-dance-architecture-01.pdf

Shumon: SMTP Client use case absent.

Viktor: SMTP client is MTA. MTA<->MTA work hard to be identified as legitimate. Audit trails and reputation. One thing we are not talking about cred exchange - start with DNS, once authenicated, switch to something else? Wow on interesting Kerberos scale - must go to recordings.

Bob Moskowitz (chat): BTW, I am looking at this approach for DRIP's unmanned aircraft certs that are behind the whole HHIT methodology. Aviation is/has built a bridged PKI (on my bridge PKI model from back in '98), but I have gotten their CP to include federated PKI. So by putting UA certs in DANCE/DANE format and federating this to the IATF I meet the ICAO goals and mine.

Paul Muchene: question on scalability. possibility of fallback solution?

Ash: up for discussion. Fallback mode useful

Viktor: fallback sounds like using DANE for enrollment.

  • Solution documents - Shumon Huque - 30m
    • https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert
    • https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid
    • https://datatracker.ietf.org/meeting/112/materials/slides-112-dance-dane-tls-client-authentication-00.pdf

Wes, relaying from chat, that client IDs (especially IOT) is privacy-leaking. Should we use just TLS 1.3 and skip 1.2?

dkg: Client Hello marked with DANE client ID?

Shumon: Not in first request...

dkg: no need for extension if you know client id is visible, let server figure it out.

Ben from jabber: it is request-response, but in the opposite direction

Robin Wilton (chat): relevant also to Viktor's previous comment about scalability: if you want to use DANE for the enrolment request/reply but not for every subsequent connection request, don't you need this kind of "bootstrapping" step in the protocol?

dkg: what we really need is just a way to identify that a cert is a dane cert

Roman: Can we go to TLS1.3 only but check use cases, thought we were using greenfield.

Ben:

Shumon: something must regenerate the chain

Ben: shipping a chain servers can require (profile)

Viktor: client needs to regenerate to send a chain. most essential is RRSIG of TLSA record. Validity at most 4 weeks. could be embedded in existing chains(?).

Viktor: could use OID for specifying name space within TLS certificates - The server presents a list of valid CAs, which could be used to select a client credential - providing the CA identifier can point to a DANE entrypoint

Olle super hard to hear, but was trying to make a point about discussing namespaces with dnsop? In Jabber clarified: The DNS namespace needs to be discussed so that we build a tree instead of a flat name space We have a potential for very large amount of clients, especially in the IOT space

  • ...
  • AOB and closing - 10m

Poll to adopt both solution docs. raise hands: 20 don't raise hands: 1 total participants: 21

dkg: wants to hear why docs are not ready from one person - No one voiced opinions about being against

How to DANCE:

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