Certificate Transparency (trans) IETF 94; 13:00-15:00 Monday 2 November 2015 Chairs: Melinda Shore, Paul Wouters Minutes by Rich Salz
STATUS UPDATE -------------------- * milestone review and reset; not great. Initial WGLC date 12/2014, proposed now 12/2015. Gossip 10/2016; threat 7/2016 * open trac issues run-down (Eran) ; 59 comments and 12 tickets closed since IETF-93 (mainly via Rob Stradling). Details: 75 wording; 5 and 70 adding extensions to STH's; 77 remove client behavior; 96 log metadata not dynamic and distribution is out-of-scope; 106 add LogID to STH; 107, make TLS-encodable; 110 reorganize requirements into separate sections; 105, shrink logid via OID's not a hash value (reduces SCT size by nearly a 3rd). Open tickets divide into three areas: missing functionality (104, 10, 109), "better wording required" where there is consensus, but editorial work needs to be done (64,76,78,93,94,95,99), technicalities/small issues (81,83,87,102,108,53,97). Feedback, particularly on domain redaction, is wanted. Bryan brought up STH extensions issue: all extensions being signed is problematic if, e.g., the thing being added is an "alternate signature" To followup offline. * implementation news? OpenSSL is implementing it. Other working on Google ref code, want to add STH extensions. THREAT ANALYSIS --------------------- (Steve Kent; not present) No comments, so ready for WGLC? Melinda: no, we need reviewers. Volunteers include: Eran, Bryan, Rich, Karen. See Steve's slides (in proceedings) for questions about the doc. Will there be an architecture document? Eran volunteered to edit, dkg volunteered to contribute. GOSSIPING IN CT (Linus Nordberg) ----------------------------------------- At IETF 93, WG adopted, no major changes to previous mechanisms; better wording including rationale. Policy recommendations. Issues: STH freshness. Protection of locally-trusted roots? Log misbehavior that is privacy sensitive? What is "same domain" for SCT feed back? Define data format for trusted auditors? Various TBD and TODO in the text. Discussion about what inclusion proof is/contains. Dkg and bryan agree embedding them in cert is probably bad idea. LOG SERVER OPERATIONS -------------------------------- Karen O'Donahue is interested in operational issues of public log servers. Governance model. What do we need to get this deployed more? If you're interested, contact her. There was post-meeting discussion about risks, e.g. POTENTIAL NEW WORK ----------------------------- * Architecture draft -- see above. * Logging binary (executable) signatures (Daniel Kahn-Gillmor/Dacheng Zhang) -- update from dkg: various participants including debian, freebsd, python pip, node.js; if you if distribute "binary artifacts" contact [email protected] Right now working on identifying common attributes. Early stages. Bryan: what if attacker turns off CT for future updates? Dkg: yes, that's an issue, but main goal is to detect unlogged/malicious software. Linus: are you protecting mis-use of existing signing keys? Dkg: yes. Paul: Fedora is interested. Are other implementations being done to allow this (generalization)? Linus, Eran: yes. dkg: No timetable yet for WG ID; if we can come to agreement, we'll come to the WG. * DNSSEC logging (Paul Wouters): Some agreement on what to log, e.g. not A or AAAA records, but rather the path. Wes: concern about parent/child relationship this doesn't protect that. Paul: not sure, but mostly concerned about domains moving across registrars and such. Have to keep every DS record ever seen? Poul: share Wes's concerns, there are operational issues similar to key rollover. Wes: useful if married to public suffix list. PHB: I'm interested in protecting against attacks from my registrar or registree. Dkg: Suggest get experience by logging the root zone. Stefan: DNS lookup doesn't imply actually visiting the site; Paul agrees. There will be a BarBof this week (per Melinda), watch mailing list. Paul: draft concentrates on data formats and we now see that there important issues to resolve first. * CT over DNS (Eran): Seeking feedback. Motivation is to preserve privacy for inclusion proofs, by not having them go to logs and disclose. New query is TXT lookup for base32-leafhash.hash.domain (slide moved too fast). Various TXT retrievals walk through the Merkle proof. Server returns as many nodes as it can (probably around seven). Also defined TXT query for sth.certid.domain Similarly TXT consistency proof query/steps. Doc in Github repo, to be updated shortly. Linus: Will it explode with 100M certs? Eran: no. Wes: how many new DNS servers? Eran: we're doing custom server, it's dynamic. Wes: is this DNSSEC signed? Eran: probably not needed since the data is signed. STH COLLECTIVE SIGNING (Bryan Ford) ----------------------------------------------- Split multiple authority functions across multiple parties so that single compromise doesn't break. This is complementary to gossip. Motivation is clients in tyrannical environment where "ruler" has stolen private keys. Raise the number of keys that need to be stolen to a very large number. CoSi: scalable collective signing. Authority generates statements; witnesses countersign in an efficient way. Uses Merkle trees, Schnorr signatures and multisignatures. Allows for server failures (assumed rare but not negligible). Implementation https://github.com/DeDiS/cothority includes integration into Google CT log server (demo shown). Interested in getting more participation. Eran: do users need all the witness keys? Bryan: no, only STH. Want feedback, too early to have a WG adopted document. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
