Minutes for DANE at IETF-93
minutes-93-dane-1

Minutes from the dane wg meeting in Congress II, 18:50-19:50, 20 July 2015

18:52: Note Well noted.

Agenda:
  Administrivia
  Olafur / Warren

  TLS extension for DNSSEC chain
  Shumon Huque

  Client Certs in DANE TLSA
  Shumon Huque / Viktor

  SMIME local part
  Olafur

Document Status:
  WGLC - none
  @ RFC Ed: dane-srv & dane-smtp-with-dane
  @ IESG: OpenPGP -> AD eval

Plan:
  SMIME doc WGLC before Yokohama
  OpenPGP usage?
  Any new docs, or shut down?  Will discuss at end.

DNSSEC auth chain extension: (draft-shore-tls-dnssec-chain-extension-01):
  Proposed new TLS extension.
  TLS server, if signaled by client, delivers TLSA record and DNSKEY/DS chain
  TLS client authenticates chain with local config'd trust anchor (usu. root)

  Sequence of RRSet structures, each of which contains the DNS rrset and
  its covering rrsig.

  Benefits:
    * client does not have to pay latency penalty of looking up
      full chain for auth.
    * if client is behind middleware that blocks its effective DNSSEC,
      can still auth the chain
    * TLS client doesn't rely on a validating resolver for DNSSEC benefits
    * Link layer auth possible, eg on EAP-TLS

  Server side:
    * Server has to build and maintain chain
    * Has to return chain at ServerHello
  ....

  Client:
    * Sends empty dnssec_chain ext in ClientHello
    * Obtain chain from server and auth
    * Use TLS to validate server cert
    * Perform 5011 trust anchor maint, or obtain via external service

  Future work:
    * Deal with CNAME/DNAME/wildcards
    * Client could cache DNS records and offer to server to let it know
      what it has already.

  Prototype code in development.

  Adds about 3000 bytes to TLS reply

 Daniel Gilmore:
    * SRV records also a challenging area.  Multiple pieces to validate.

 Christian Wultoff(?)
    * Kind of turns TLS/DNS upside down.  Really confuses layered
      architecture.  Personally would prefer to keep DNS below TLS.

 Viktor via Dan York:
    * Should RRsets proving a non-delegation of intermediate nodes
      between apex and name be included?  Shumon: No, that'd mean no
      chain because the TLSA isn't secure then.

 Paul Wouters:
    * Would be good to use the EDNS0 chain query proposal to make
      building the chain easier.  Also, use wire format.

 Shumon:
    * I wish we could just use wire format, but are constrained by app dev
      expectations.

 <name>?
    * How do TLS library developers feel about this?  Shumon: We've
      talked to app people but not lib people yet.

 <name>? (App guy)
    * This is a positive step to making things simpler for devs.

 Daniel Gilmore:
    * Pushing back on layered architecture comment.  We have software
      that better handles interdepencies like this.

 Peter Koch:
    * Should you let the root signing people know there's another
      potential consumer of 5011 rolling now?

 Wes Hardaker
    * Do we really need to include the root dnskey?  Shumon: yes, for
      trust anchor rollover.

 Paul Hoffman
    * Which WG?  Author said tls, but questions have been very DNS-y.
      Shumon:  We'll be asking in tls.

Client Certs in TLSA recs (Shumon):
    Owner name proposed:
     _<service>.<domain-name> IN TLSA <rdata>
     _smtp_client.dev1.example.com IN TLSA ( 3 1 1 .... )

    Auth model:
      client has identity
      client has a pub/priv key pair and a cert binding the domain name to pub

    Client id in cert:
      option 1: DNSName type
      option 2: SRVName type (if want isolation of apps)

    Signalling client id:
      Server may want explicit indication from client that is has TLSA
        to avoid unnec. DNS lookups
      If raw pub keys are used (RFC 7250) client needs to convey id
      Some deployed clients react badly to unexpected client cert reqs

      Proposed: New TLS ext. to convey TLSA client id (draft in near future)

    Client and Server requirements:
      ...

 Thomas Shaeffer(?)
    * Couldn't you do this like the server chain proposal and have the
      client send its chain up to the server.  Shumon: Server not generally
      constrained by middleware like clients are so it seems better to
      have the server do the DNS, but it could.  Thomas: What about "clients"
      that are servers themselves, like SMTP servers?  Shumon: Sure maybe.
      Viktor via Dan: Yeah, servers can just do it better, don't need to
      do to avoid the last mile problem.

 Daniel Gilmore:
    * Client can't really protect its side of ServerHello enough so
      don't want to leak more metadata by offering this info up in the clear.
      Shumon: Agreed.

How to find right cert?
  OpenPGP ... _OPENPGPKEY
  S/MIME ... _SMIMECERT

  Can we reduce these knobs, to use zone/label?

  Paul Wouters
     * Funny enough this came up before and it was asked why not use
       CERT type with subtypes, but the CERT author said no and now
       he's dane wg chair and wondering whether we should use
       subtypes.

  Dan York:
     * Already seeing an issue getting these records deployed anyway.
       Hard enough just getting basic TLSA records in.  I worry about
       having too many records types when dealing with the realities
       of provider provisioning interfaces.

  Peter Koch:
     * Most DNSSEC zones I see is managed by the registrars behind the
       scenes.  Manual is not so much of an issue; there is
       automation.  Can we have an assessment of what sort of numbers
       we're talking about to use this?  Have some patience.
       Throttling back might be more warranted for now.

  Dan York:
    * I totally agree with wanting automation, I'm just sharing my
      experience with trying to tell people how they can do this and
      they hit roadblocks with the interfaces of their providers.

  Paul Hoffman
     * People who are motivated are going to make it work.  It's just
       software.  Arguing with no data is a real problem.  Bad data that
       we can't measure is no data.

  <name>?
    * dane is not the right place to solve this.

  Mark Andrews:
    * We can use DNS UPDATE to add any record to any server.  We
      should be leaning on the registrars to just take opaque records
      via UPDATE.

  Viktor via Dan:
    * What's the question again?  Are we only talking about qname
      unification or rrtypes or ...?  A: qname

  Paul Wouters:
    * Really should unify rrtypes as openpgp and smime people want to
      do different things.

  Warren:
    * Need reviewers for S/MIME doc.
      Paul Wouters / Tim Wicinski / John Levine / Russ Housely /
      Daniel Gilmore / Ted Lemon

  Paul Wouters and Paul Hoffman:
    * How can we move on with the current drafts when the current
      proposals are not included, and the consensus seemed to be
      "whatever draft goes first, the other should follow suit"?

  Paul Wouters:
    * Let's decide on the approach based on current proposals.

  AV via Dan:
    * Why local part in OpenPGP and S/MIME are different?
      A: They will be the same

 Paul Wouters:
    * Only the base32 split proposal supports online signing.

 John Levine via Dan:
    * Email is dominated by a handful of large providers with millions
      of users each.  Has anyone besides me talked to them about their
      thoughts on this?

 Paul Hoffman:
    * No, pretty much just John.  Appreciate his concern but think
      even if we completely blow this we can fix it later.

 <name>?
    * Base32 needed for fuzzy matching as well.

 Warren:
    * Any objections to the base32 idea?  (Seems like no.)
      Hum for the options.

 Paul Wouters
    * But wait!  There is a b32 problem, privacy.

 DKG:
    * Right, b32 leaks the information easily.  But to a powerful
      attacker the hash ends up leaking it also.  The other privacy
      concern is whether you can enumerate all of the addresses on a
      host.  This is probably equivalent.

 Warren:
     Hums:
     1. I am ok with b32.       moderate + 4 hums from jabber.
     2. I am NOT ok with b32.   quieter + 2 hums from jabber.
     3. I dunno; investigate.   Louder than quiet but less than moderate.
   No consensus.  Will continue this on the list.  I don't know how we get
   to the point where we can reach agreement.

 DKG:
   * My impression of the last hum was that it represented two sets of
     people, those who didn't really know vs those who really thought
     we should make a decision right now.

 Warren:
    * Re-hum on item 3.  Do you think we should not make a decision
      right now?  (Quietish hum).  I'm going to take it back to the
      list.

 Paul Wouters:
    * I really don't want to take it back to this list because this
      has been going on for way too long.

 Warren:
    * We'll work to get it resolved quickly this time, without waiting
      until next mtg.