Minutes for TRANS at IETF-93
minutes-93-trans-1
Meeting Minutes | Public Notary Transparency (trans) WG | |
---|---|---|
Date and time | 2015-07-23 15:40 | |
Title | Minutes for TRANS at IETF-93 | |
State | Active | |
Other versions | plain text | |
Last updated | 2015-08-13 |
minutes-93-trans-1
TRANS WG MINUTES, IETF-93 Meeting Thursday July 23, 2015 Afternoon Sesssion III: 17:40-19:10 Chairs: Melinda Shore, Paul Wouters Responsible AD: Stephen Farrell Minute-taker: Rich Salz Paul, WG Status update Charger unchanged; need to reset milestone dates. # Eran RFC6962-bis status Still needs some tweaks. Suggests waiting for Google to finish their implementation to clean out all nits before WGLC. A log cannot do a single v1/v2 log, must run both in parallel. Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; see tracker for details Open tickets 78 (alg agility needs more description) 83 (should require deterministic ECESA) 96 (dynamic metadata; does only CA root list really change?) 95 (include get-entries response size in the log metadata, for cursoring through a log) Steve raised issue of exposing what certs a client is interested in if size of get-entries can shrink to one, for example. Eran answer: this doesn't matter so long as the client continues to request entries until it has all the ones it originally decided to fetch. More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash lags) 93 (monitor description inconsistencies) 94 (when/why clients should fetch inclusion proofs) Stephen pointed out that if threat analysis is normative, schedule gets pushed out further. Should be informative. # Steve Kent, attack model Name changed on doc, even if filename can't easily be changed. Not a threat model, we don't know what the attackers are thinking, but we do know possible actions so it's an attack model. Includes an intro to CT, he prefers it move into an arch document but if not it will stay. There was some talk about whether or not an architecture document should be started. "CT is a set of mechanisms, designed to detect, deter, and facilitate remediation of certificate mis-issuance" Semantic mis-issuance: name in the cert refers to an entity incorrectly. Syntactic mis-issuance: violation of certificate profile(s) that apply. Reviewed a taxonomy of attacks. Read the doc. Discussion of additions and bigger picture needs. Incorporated all (but one) comments. Wants WG agreement via list on goals, definitions, attacks. We have a half-dozen people commit to read and review the document. Ben agrees about having an arch doc. Others volunteered (Eran); to be taken to the mailing list. # Dkg, Gossip Gossip important to keep logs accountable by making sure everyone sees the same append-only data and keep their MMD/SCT promises. Works by browser's sharing and comparing SCT and STH Three channels: 1. SCTFeedback; browser sends cert/sct to website, website sends to auditing function/third-party auditor 2. STH Pollination: auditor/website send STH to each other. STH are not privacy-sensitive. 3. Optional Trusted Auditor: browser passes sct/cert to auditor (e.g., the DNS resolver since it already knows what you might be looking at) Call for adoption is on the mailing list. # Dkg, CT for binary Goal is to know that you are running the same software as "everyone else," not guaranteeing that the software isn't compromised. Add a binary LogEntryType; add binary and binary_digest to Signed_Type. Many details of what and how is signed are still open; need feedback from s/w distributors. PHB suggest to not use ASN.1 Discussion and agreement that changing the s/w distribution format is a non-starter. dkg also noted that some distros (at least Debian and FreeBSD) have been discussing the question of what exactly should go in the logs. He'd like to hear from anyone interested in joining those discussions. # Rich Salz, selective logs Some logs will not log every single cert from the CA's in their root list. What do we do? Discussion, no conclusion.