Trans working group minutes, IETF92
13:00 - 15:00 Monday 23 March 2015 

Status
======
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
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 -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
client behavior

Sense of room is to adopt as a WG document; will go to
mailing list for consensus.

 

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 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
 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?
Steve Kent volunteered to edit, will be taken to trans
mailing 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