IETF attendees, please post corrections.
One milestone, we’re late; IETF tradition.
Using issue tracker.
Anyone implementation updates? Nordunet and akamai still active
Ben and Eran hampered by lack of audio
RFC 6962-bit update
Threat Analysis (Steve Kent)
Threat is a motivated capable adversary; threat analysis (see RFC 4949), taxonomy of actors and classes
Threat analysis requires that security functionality or goals be clearly articulated
Most don’t need this, just Security Considerations, since they’re not security protocols
CT is a complex security system with many elements and thus seems to merit a threat analysis
Why? Can help guide system designers; after design, helps users understand what it provides
Mis-issuance is either syntax (bad profile) or semantic (to a wrong entity)
Malicious CA vs not-malicious; errors vs attacks; logged vs not logged; benign vs conspiring logs
Detailed outline of attacks
Missing in current text
List of adversaries?
Concise statement of security goals, such as “the goal of CT is to deter, detect, and help mitigate certificate mis-issuance”
Part of 6962-bis or separate doc? (No strong pref, but perhaps bis is long enough already) If separate, perhaps rename to include “logs” in name since it doesn’t talk about client behavior
Consensus to adopt as a WG document; will go to mailing list for confirmation
Gossip keeps logs accountable (e.g., meet MMD, not present spli view of tree head)
Monitors are auditors, not all auditors are monitors
Biggest issue is privacy considerations; relationship between clients and servers, but not between auditors/log and server/log – speak up if you disagree
Gossip happens among various parties (see preso)
Recommend mix in “noise” in auditor response to avoid disclosing browser history
Terminology confusion: TLS client vs log client, e.g.
Some updates to the (nice) multi-party pictures and flows offered
Not enough people read it; premature to talk about adoption, but it got well-received in the room will raise on mailing list.
Open issues in trac (eran)
#4 sign TBS for certs? Consistent with precertificates, avoid bad encoding of sig params. Good idea, yes.
#10 – blinked and missed this, sorry
#41 – handled by steven kent
#53 – requiring logs to order entries; no, clarify it’s not a requirement
#55 – security considerations, no since going to define client behavior
#58 – limit STH’s per unit time; hard to enforce
Client behavior – 20 tickets, slot on agenda
#8 client privacy; significant change, but not be enough; postponed
Any interest in a document describing client behavior? No enthusiasm; to be on list
RFC 6962-bis update
Handled server time skew
Added machine-readable error codes to responses (e.g., malformed request, invalid cert, etc)
New API merges Get STH, get Consistency:Proof, get InclusionProof
Added metadata for log parameters (including final STH for frozen logs); comment if anything missing
Algorithm agility: propose to freeze log, start new one; if necessary, will have to include all old data in the new log.
See Steve Kent’s open issue, which pointed to an RFC for some ideas and more details; agree need more details on what clients should do when this happens
Senior Architect, Akamai Technologies
IM: rsalz <at> jabber.me Twitter: RichSalz