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. ? * How do TLS library developers feel about this? Shumon: We've talked to app people but not lib people yet. ? (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: _. IN TLSA _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. ? * 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. ? * 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.