# dance @ IETF 116   {#dance--ietf-116}

## Meeting information   {#meeting-information}

Time: Tuesday, 2023-03-28 -- 15:30 local -- 06:30 UTC  
Location: G303

## DANCE agenda:   {#dance-agenda}

*   5m - Chairs Introduction (Wes and Joey)
*   10m - DANCE Last Call results and discussions (Wes and Joey)

*   20m - Updates on [draft-ietf-dance-architecture][1] (Olle and
    Michael)
    *   Neither presenter was available, item skipped

*   15m - Open mic / use case presentation (Wataru "alt" Ohgai)
    *   Mutual Declaration Mechanism of Multi-provider Relationship for
        Trusted Web Services
        *   Use DNSSEC to create lightweight/self-manageable trust
            declaration mechanism for website redirects
        *   Use case: redirected to enter credit card info on payment
            site from online shop
        *   not DANE/TLSA-based
    
    *   Wes: why not DANE/TLSA-based?
        *   Goal is to have users be able to re-create/verify the
            hashes, which is why we opted for TXT records (unclear)
    
    *   Viktor: very puzzled as to why you want servers to sign the
        other's keys. It removes ability of the server to independently
        update their key. Why do keys need to be attested by someone not
        in control of the key?
        *   From end user's point of view, even if web servers are
            separate, they may be part of the same web service
    
    *   Amir: If you trust TLS certificate on the origin side, and the
        website authenticated w/ TLS is pointing you to another site,
        how as an end user does this improve trust in the site?
    *   Wes: similar question. To rephrase, it's very difficult to show
        the user there is no link that exists

## Open mic   {#open-mic}

*   John Levine: since there's extra time, some suggestions on draft re:
    email
    *   Wes: Please put in text/PRs/mail list
    *   John: tl;dr summary version
    *   Overlapping protocols, SMTP and submission
    *   Certificate-based authentication exists for submission
    *   There are some cases where clients will positively identify
        themselves to a server

*   Viktor Dukhovni: in SMTP, some organizations actually want to know
    that mail from a particular client is from a particular entity at
    the transport layer, allow
*   John: Once you know it's "x", what do you do about it?
*   Viktor: Could theoretically drop or filter etc, but doesn't expand
    past one-to-one client relationship



[1]: https://datatracker.ietf.org/doc/draft-ietf-dance-architecture/