Subject: [Trans] IETF 92 Meeting minutes

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Mar 2015 19:06:12 +0000

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-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Mar 2015 10:52:51 -0500

Much gratitude to Rich for getting the minutes done.  All,
please review.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Mar 2015 19:22:03 -0400

Rich,

> ....
I volunteered to work on this, noting that I had already documented proposed
Monitor behavior on the list, and proposed optional log behavior as well.

Steve

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 26 Mar 2015 00:07:15 +0000

>Monitor behavior on the list, and proposed optional log behavior as well.

Thanks for the correction!