Skip to main content

Minutes for TRANS at IETF-93
minutes-93-trans-1

Meeting Minutes Public Notary Transparency (trans) WG
Date and time 2015-07-23 15:40
Title Minutes for TRANS at IETF-93
State Active
Other versions plain text
Last updated 2015-08-13

minutes-93-trans-1
TRANS WG MINUTES, IETF-93

Meeting Thursday July 23, 2015
Afternoon Sesssion III: 17:40-19:10
Chairs: Melinda Shore, Paul Wouters
Responsible AD: Stephen Farrell

Minute-taker: Rich Salz

Paul, WG Status update
Charger unchanged; need to reset milestone dates.

# Eran RFC6962-bis status

Still needs some tweaks. Suggests waiting for Google to finish their
implementation to clean out all nits before WGLC.

A log cannot do a single v1/v2 log, must run both in parallel.

Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90,
82, 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; see tracker for details

Open tickets 78 (alg agility needs more description) 83 (should require
deterministic ECESA) 96 (dynamic metadata; does only CA root list really
change?) 95 (include get-entries response size in the log metadata, for
cursoring through a log)

Steve raised issue of exposing what certs a client is interested in if size of
get-entries can shrink to one, for example.
Eran answer: this doesn't matter so long as the client continues
to request entries until it has all the ones it originally decided to fetch.

More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash
lags) 93 (monitor description inconsistencies) 94 (when/why clients should
fetch inclusion proofs)

Stephen pointed out that if threat analysis is normative, schedule gets
pushed out further. Should be informative.

# Steve Kent, attack model

Name changed on doc, even if filename can't easily be changed. Not a threat
model, we don't know what the attackers are thinking, but we do know possible
actions so it's an attack model.

Includes an intro to CT, he prefers it move into an arch document but if not
it will stay. There was some talk about whether or not an architecture document
should be started.


"CT is a set of mechanisms, designed to detect, deter, and facilitate
remediation of certificate mis-issuance" Semantic mis-issuance: name in the
cert refers to an entity incorrectly.  Syntactic mis-issuance: violation
of certificate profile(s) that apply.  Reviewed a taxonomy of attacks.
Read the doc.  Discussion of additions and bigger picture needs.

Incorporated all (but one) comments.

Wants WG agreement via list on goals, definitions, attacks.  We have a
half-dozen people commit to read and review the document.  Ben agrees
about having an arch doc. Others volunteered (Eran); to be taken to the
mailing list.

# Dkg, Gossip

Gossip important to keep logs accountable by making sure everyone sees the
same append-only data and keep their MMD/SCT promises.  Works by browser's
sharing and comparing SCT and STH

Three channels:
1. SCTFeedback;  browser sends cert/sct to website, website sends to
auditing function/third-party auditor
2. STH Pollination: auditor/website send STH to each other. STH are not
privacy-sensitive.
3. Optional Trusted Auditor: browser passes sct/cert to auditor (e.g.,
the DNS resolver since it already knows what you might be looking at)

Call for adoption is on the mailing list.

# Dkg, CT for binary

Goal is to know that you are running the same software as "everyone else,"
not guaranteeing that the software isn't compromised.

Add a binary LogEntryType; add binary and binary_digest to Signed_Type.
Many details of what and how is signed are still open; need feedback from
s/w distributors.

PHB suggest to not use ASN.1

Discussion and agreement that changing the s/w distribution format is
a non-starter.

dkg also noted that some distros (at least Debian and FreeBSD) have been
discussing the question of what exactly should go in the logs. He'd like
to hear from anyone interested in joining those discussions.

# Rich Salz, selective logs

Some logs will not log every single cert from the CA's in their root list.
What do we do?

Discussion, no conclusion.