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