Minutes IETF97: trans
minutes-97-trans-00

Certificate Transparency (trans)
IETF 97: 11:00 - 12:00, 15 November 2016
Chairs, Paul Wouters, Melinda Shore
Minutes by Allison Mankin


[The AV isn't working, so we are using imaginary slides]

Status update
------------

Other items for the working group include that gossip and
binary object drafts exist, but moving slowly.  Melinda asks
if the proponents of the binary app are in the room.

Eran Messeri speaking about 6962bis update:  a few issues
are left.  
Some log operators expressed interest in limiting certs
accepted - need more options for restrictions on accepting.
Two ways to address:
    1. reopen, find a way for clients to query to see if
    they were accepted
    2. change MUST to SHOULD, logs that behave differently
    will still comply.  That is Eran's proposed solution for
    the first issue
    
Second issue is about a new optional API for monitoring.
Some exist in the bis already, e.g. looking up a cert by its
hash (versus an entry by its hash).  

Name Redaction
--------------

THird open issue is privacy concerns:  what if a cert with
private info finds its way to the log and owner doesn't want
it to be there, or if logs have to remove a cert because of
a legal or other issues.  This could be done technically.
It is not the same as name redaction.  Suggestion build on
top of 6922bis rather than delay 6922bis in the meantime. 

Melinda: a goal is to have fairly minor changes and not do a
whole new WGLC.

Alexey Melnikov (acting AD for session) - you don't have to
do another WGLC

Ryan Hurst - his opinion is that the changes are all pretty
minor, the biggest one is the MUST -> SHOULD and that should
be policy.

Alexey: if you will change MUST -> SHOULD, good idea to add
some text explaining, it will help the IESG in their
review.  

Paul asks about a PR for this change - Eran: it doesn't
exist yet, but given this minor change, it's easy to do  a
PR

Ryan H - if it was left as a MUST, pretty much all CAs would
violate it anyways.

Name Redaction was taken out of the base document.  Eran has
slides about the potential solutions.  See them in the
tracker as we continue to have AV problems.  

Definition of Name Redaction: the ability to avoid
publishing domains names in the logs.  Hide certain parts or
the entire domain name from the log certification.  Can only
be done for pre-certs, not for final ones used by clients.  

First idea as to replace each redacted label with ?  and an
indicator saying how many labels were redacted.  Client must
reconstruct the redacted labels to check the
signature. Problem is client doesn't know what was intended
in the ?s from among many possibilities.

Second possible solution - monitors/clients that know what
the possibilities are, can verify that the labels redacted
go with one.  Use hashes of the redacted labels or salted
hashes of them.  Still have in pre-certificate.  Problem
with this solution is that it can be reversed by brute force
attack.

Third solution - salt is moved from the pre-certificate to
the found certificate, making it harder for observers to
undo the redaction.  

Spent a lot of time trying to engineer all this, complicates
clients, monitors, increases protocol complexity and WG
could not get to a consensus.  CAs and Browsers both
unhappy, and requirements weren't clear.  So this become a
separate document to complement 6922bis.  Need to know the
requirements.  E.g. do you want to redact more than the DNS
names. Eran offers that people also contact him directly
with info on requirements and he can summarize to list, for
those who aren't sure about public discussion.

Paul Wouters - did they shape up a redaction draft?  There
is one by Rich Salz, is this the one that is in play?  Eran
says that Rich's document includes one of the solutions at
least, and there was a need to get WG adoption.

Paul Wouters - can this also be used to help with issues
around personal certificates?
Eran - if the personal cert needs full removal from log, it
is not covered by redaction, but redaction could apply to
some personal cert needs.

Ryan H - personal certs are a great example where we need
requirements or use cases to settle what's in the redaction
draft.  This new draft needs to capture scenarios more
clearly, right now it's a "great tool box, something for
everyone"

Paul: are there personal cert issues for the bis documents.
Ryan H says no.

Ryan Sleevi:  I think with the MUST -> SHOULD change, the
bis document has no personal cert issues.

Peter Bowen (remote): there's how do we technically do this,
and separately, should we do this?  Subject names frequently
end up with personal info in them.  Logs might be able to
reject certs now, but it's not clear if certs should be
rejected because they appear to have personal info in them.

Eran: are you saying that policy change from MUST to SHOULD
won't be enough for the bis to handle personal certs?

Peter: no, what will we do with a cert for a website that
has a first and last name in 

Ryan H: can we ship these issues into the redaction draft
and let the bis go forward?  Peter says yes.  

Peter: another scenario that maybe still should be in the
bis document is binding of knowing who is the issuer of a
cert to various certs - knowing examplecorp's CA issues
newthing's cert can breach a corporate secret.  This can be
in the redaction draft.

Final issue in bis: addition of the API for historical
fetching.  Eran thinks it's a nice option, but it would be
good for it to be in a monitoring API document.

Ryan H: someone not in the meeting would like there to be a
REST API - good idea to have a broad query API rather than
bolting optional APIs in the bis document. 

Conclusion: small update and put the document into IETF LC

Eran: note he has a personal (github) reference
implementation.  Currently only supports add-chain and
get-sth, does not validate chain.

New Items
---------

Two new items:
    Log monitoring API - no body here for this
    
    Expact CT TLS header, which will be discussed in the
    HTTPBIS WG on Thursday
    
Threat analysis
---------------
    
Chairs:  Looking for a volunteer to serve as editor of the
threat analysis and get it to the finish line.  Eran accepts
the task and he will make sure it's consistent with bis.   

DKG: feels a bit responsible having raised the dual-CA
attack.  Too much discussion, too verbose.  In terms of
specifically describing the dual-CA attack, the text in the
latest version of the document is correct.  "Haven't looked
at it recently because I didn't want to retraumatize myself"  

Melinda: right way to break it down: delete all previous
state.  Take a look at current document, David's response to
current doc, and nothing prior to that.  David's posts are
pretty self-contained.

Paul endorses this view.  

Rich Salz: if you look in recent Chromium and Mozilla
mailing lists, it's become almost an NP-Hard problem these
days to figure out whether two CAs are administratively
different from each other.

DKG: not sure if that's relevant.  There are two different
particular public keys associated with two different CAs.
Rich: the attack is more relevant today, because there are*
multiple things under the control of one party.  

AOB:  NONE