Minutes for TRANS at IETF-92
Public Notary Transparency
||Minutes for TRANS at IETF-92
Trans working group minutes, IETF92
13:00 - 15:00 Monday 23 March 2015
One milestone, we’re late; IETF tradition.
Using issue tracker.
Anyone: implementation updates? Nordunet and akamai still active
[Ben and Eran remote presentation hampered by lack of audio]
RFC 6962-bis update
Waiting for remote audio to be fixed.
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
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 -bis draft 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
Sense of room is to adopt as a WG document; will go to
mailing list for consensus.
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 was 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
#55 – security considerations, no since going to define
#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?
Steve Kent volunteered to edit, will be taken to trans
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
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