IETF attendees, please post corrections.
Status
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
Current text
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 (dkg)
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: [email protected]<mailto:[email protected]> Twitter: RichSalz
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
