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

IETF Public Notary Transparency Working Group

5 March 2014, 15:20 - 16:20

Minutes by Mark Donnelly, summary by Melinda Shore

1) agenda bashing, administrivia

2) status update  (Melinda Shore)

   This is the first meeting of the working group.  We have
   a charter but need milestones.  How's late 2014?  Ben: in
   terms of Google's timeline (implementation), don't think
   we can finish in time to change google's stuff, so we'll
   have some sort of code transition.

   We have an issue tracker
   (http://tools.ietf.org/wg/trans/trac/report/1) and an
   IETF wiki (http://tools.ietf.org/wg/trans/trac/wiki).

   Should we split out portions of the document to stand
   alone?  Seems to be support for doing that, take it to
   the list

3) Document status  (Ben Laurie)

   We have a bunch of stuff in trac and those need to be
   taken to the mailing list.  There's a problem with those
   being automatically forwarded and we're trying to get
   that fixed.  There's more that needs to go into trac, and
   Ben and his team are working on that as well.

   Discussion of issues around private subdomains.
   Discussion of issues around proof of inclusion.  Taking
   both out to the list.

   Next steps: Ben thinks all of what's been discussed will
   be included in the next revision of the document.
   Further discussion of splitting out sections of the
   document, particularly client behavior.  Other proposals
   included splitting out entities, log management, log
   auditing, other applications.

4) Issues list  (Eran Messeri)

   Specification-related issues have been copied from the
   Google tracker into the IETF tracker, look for yours.
   This is a public issue tracker and working group
   participants may create or comment on tickets (nothing is
   closed without working group agreement).  We'll restrict
   access if there's abuse but for now it's open.

5) Certificate reputation  (Tony Nadalin)

   Presentation of a different approach to identifying
   certificate misissuance - out of scope for trans but
   likely to be of interest to working group participants.

---------

Raw notes:

Melinda: have a charter
... milestones: late 2014
... open question: should we split out the document?
... have an issue tracker, and IETF wiki
... issues ha
Ben Laurie: timeline - don't think we can finish in time to change google's
stuff, so we'll have some sort of code transition

Document status, by Ben Laurie (Googe)
=====================================================================
Ben: have a bunch of stuff in trac
... won't talk about most, but
Stephen Ferrell: be careful that TRAC comments make it to the mailing list
Melinda: We know it's an issue, and we're fixing that
Ben: We have more stuff that needs to go in TRAC, working on that too

Slide 2
------
Ben: Issue - private subdomains
... proposal 1: allow named constrained intermediate to be logged
... Proposal 2: allow pre cert to literally say that I'm private from here on
down ... private has no name ... people watching the log can decide whether to
trust privates for themselves

Slide 3
-------
Ben: This introduces a side effect
... the private cert might accept unintended matches

Slide 4
-------
Ben: Want to make sure that all of the logs see the whole logs
... gossip STHs between parties to detect inconsistency
... servers maintain a pool of STHs sent by clients
... questions: how many to send, and when

Slide 5
-------
Ben: Privacy issue that might crop up
... when you get something that needs verifying
... have to ask a log for proof of inclusion
... maybe have the info in the TLS handshape

Slide 6
-------
Ben: other side of inclusion proof lookups - DNS query mechanism
... or a batched query; ask for proof of inclusion for a group
... log only knows about that you asked for

ekr: have you looked at any more sophisticated PIR approaches?
Ben: That's expensive; there are cheaper schemes that we're persuing
ekr: We have a similar problem in STIR (security for CallerID)
... have a database of numbers to look up
... Anyway, there can be multiples of these objects, right?
... had a chat at workshop with George, have something clever to do

Daniel Kahn Gilmore: Goal is detection of misdeeds, identify CAs that are doing
the wrong thing. Ben: right DKG: but we're not going to block the loads while
we're waiting, right? Ben: right DKG: if we don't have the stapled proof, we're
not trusting the CA or the log, right? Ben: DKG: Without a global bit, if you
have a phony SCT, you keep going? Ben: The goal isn't prevention; it's quick
detection so the user can act ... and so that we can let the world know DKG:
How do we prevent random bitstreams? Ben: SCT => Signed, so random won't work
... Logs have to agree.  After a timeout, it's assumed to be a misbehaved. ekr:
Major consumer of this technology will be web browsers, right? ... is a part of
this to have Chrome phone home to find the heads? Ben: we have to push the logs
to chrome anyway, so we could push the heads, too ... that would reduce the
load on logs ekr: Chrome and FF do SafeSearch queries for every site they
attend ... is there a similar mechanism here? ... ask Google, please give me a
... Ben: I suspect not, but I welcome any suggestions ... unlike safesearch,
this needs to give proof rather than using a heuristic

Melinda: in terms of next steps, what will be the next revision, and included?
Ben: I hope all of these things will be included, as well as TRAC
... I think this is complete
Melinda: How about splitting out the client behavior stuff?
Ben: You might wind up with duplication, and mean that you have to read both
papers Aran with google: why the split? Melinda: Might get one out sooner PHB:
Like to split them up; people might find value in notary beyond this
application ... otherwise people will build on CTs in ways that this app
doesn't like ... and when you force the division, it usually improves the
quality of draft Ben: that's a different split than discussed - splitting
notary off, right? ... I'm not signed up for this ... we have profiles for
notary, and then things that use it ... we have chosen to include in signature
... originally we included the proof of inclusion, but CAs find that too much
... nailing down all the option like that will be painful ... possibly a
worthwhile exercise, but not one that I will do for now Melinda: and the
charter is focused on TLS PHB: but we want the spec to be solid ... this can be
a quality issue ... if we split to multiple domains, this improves the
architecural division Melinda: Are you signing up? PHB: I'll provide a draft
???: I think that this draft should be split in four parts ... entities ... use
case with TLS ... signaling to management of the log ... Auditing the log ...
because for the two last parts, actors may be not the same ... capabilities may
not be the same ... http might not be used to do the auditing Ben: I don't care
about how it's split ??-2: We don't have to do it all right now, we can have
future works Leif Johannson: Understand the pain of not having the resources
... and the desire to push docs out quickly ... lots of people think it's
better split ... and so do I, because I can see use of some parts without the
rest ... maybe have a paragraph at the beginning deliniating the split Ben:
That still leaves you with a set of documents applying to TLS ... and that's
our charter Leif: Call for extra authors, in the mailing list Melinda: It's the
IETF, so I'll say next: Give me text

Issue List
================================================================
Eran Messerie: the issues are on the tracker
... issues are migrating
... look for yours
... if you can't create a new ticket, you need to log in to the site
... as for when, use your best judgement
... currently edit the RFC itself on the google code site
... accept patches and pull requests

Melinda: This is a public list, feel free to take it there
... I'm surprised how quickly this is going
... maybe it's due to the list renaming
... are the people from Microsoft here?
... I don't have slides here, do you want to plug in your laptop?
MS-Person: I can mail them to you

Microsoft Presentation:
================================================================
Tony Nadlin: having problems geting slides
Tony Nadlin: I'm Tony Nadlin from Microsoft
... want to present alternative ways to accomplish the goal
... we've done some things for web page reputation
... done cert reputation for quite a while
... mainly we have Smart Screen - for reputation for web pages
... added in certificates as part
... try to detect fraudulent certs
... find independent names with the same hash
... find different certs with same cert hash
... certs renewed too early
... two or more certs with the same DNS names
... slides will be up soon
... and we also do cert hygenine analysis
... end-entity certs with constraints
... CA certs without enough entropy
... entity SSL certs issued directly under the root
... weak crypto analysis: 415K signed binaries that used 6500+ signing
... detect the weak crypto
... also have cert reputation mitigation - finding supicious, non-hygenic certs
... we either talk to CA or the site owner
... it's not a stop situation
Ben: So, one of the objects in early days of CT is that it introcuced another
trusted third party ... that sounds like what this is doing ... why trust this
service? Tony: We're not doing so ... for our own internal use, we're trusting
ourselves ekr: the point is that the browser came from them Tony: We're not
stopping anything from going on ... trying to clean up the web here ... not
stop anyone doing business Warren: you said multiple certs from same DNS name
... that means that something is sketchy, not an error Tony: that's correct
ekr: how much is this a system for finding bad stuff versus providing a service
to the user Tony: not a notification to the end user ... user might see a bar
on IE to say beware ... we haven't gotten to the point of showing the user the
cers ... assume this would be displayed eventually ekr: and the user already
has a trust relationship with you PHB: one of the disappointes with the
certifiicate observatory is that after running, it stopped ... we have
interesting data ... how do we feed it back into the system? ... through
browser?  Through DNS? ... institutionally, can this be used to give a bad CA a
beating? ... or give browsers a beating?  (Apple, etc.) Tony: Basically, we're
detecting fradulent certs, enablying hygene analysis Stephen Ferrell: This
isn't associated with this WG, right?  This is just a different alternative
approach Tony: Yes ... it's an alternative; is the group interested?  Would the
group want to merge with this? Melinda: We have a charter, and we're scoped to
deal with the logs Stephen: if we discover overlap later, we can pull that in
... what do you think of your work?  What do you think the IETF's role in what
you do will be Tony: we're not the only ones who can do this  analysis ...
we've done this with SSL binding ... what we'd break if we stopped certain SSL
algs ... so this will be informative work for the IETF ... to know what sort of
certs exists out there? Stephen: would there be a draft for that? Tony: maybe
Stephen: would there be IPR on that? Tony: Dunno ??-3: Tony: we haven't mada
anything public yet, but we'll get you the slides

Melinda: we're done today
... will put things on the mailing list