Secdispatch Status PagesSecurity Dispatch (Concluded WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2018-Mar-09 —Chairs:
IETF-107 secdispatch minutes
Session 2020-03-27 2000-2200: Virtual Track 1 - secdispatch chatroom
Secdispatch @ IETF107 Friday, March 27 2020, 20:00-22:00 UTC Chairs: Francesca Palombini, Kathleen Moriarty, Richard Barnes Recordings: https://www.youtube.com/watch?v=aTfF8teKFpQ Jabber room logs: https://www.ietf.org/jabber/logs/secdispatch/2020-03-27.html Minute takers: * Bron Gondwana * Rich Salz Jabber scribe: * chairs ********************************************************************** Agenda & Minutes ********************************************************************** 1. Logistics and introduction (chairs, 10 min) New wiki, https://trac.ietf.org/trac/secdispatch/wiki Agenda bash: Roman Danyliw: thanks for putting the wiki up. It's critical for us as the IETF to make it easy to find the right way to bring work. 2. Dispatch items == 1. Signature Validation Token (SVT) == [https://mailarchive.ietf.org/arch/msg/secdispatch/VhtsrzIyjDcXZYDT3e3p_aQlV9Y link to mail post] * presenter: [mailto:email@example.com Stefan Santesson] * time allocated: 25' * objective: get feedback; standardize SVT in IETF. * specification: https://docs.swedenconnect.se/technical-framework/index.html#sigval Goal is to have simple solution for validating signatures in a distant future (compoare with ETSI sigs) Current approach is like a time machine: time-stamping signs all data so you can resurrect signature and credentials at the time of original signing SVT is an assertion signature was checked at the time it was signed. Ben Kaduk: * First half: "in the future we will be able to validate" * Second half: "knowning in the future that this signature is still valid" * Before doing this work we should know what the actual requirements of the users are. Comment from Jabber, this is more "note to ourselves that we have checked the signature". EKR: * Q: is this designed to protect against original algorithm being broken? Isn't that the same problem? A: No because you don't need all the source material (document, CRL, private key etc). You just need a "new" SVT. Admit this is a hard sell to understand. Francesca: clarification questions are good, but remember we're trying to work out where to dispatch it. Roman: * This seems like a substantial body of work, is this too much for LAMPS? Ben Schwartz: * Q: What if someone comes with a 512bit RSA from 2000? * A: TSA can't sign that because it's not trustworthy. Need to bring it to the TSA while it's still verifyable. Richard Barnes: * Q: Why does this need a spec? Is there a need for interop? * A: There may be an interest in being able to verify each other's SVT tokens. From DKG on Jabber: * Q: is there a reason why this needs to be in the document rather than travel alongside? * A: no need to be embedeed. Chairs: think it needs more discussion, would like to hear what the ADs have to say: * Roman: If there's interest we could start up a mailing list, maybe BOF is next step. Conclusion: Need to build more community. == 2. Client-Cert HTTP Header == [https://mailarchive.ietf.org/arch/msg/secdispatch/7JQLB8Z2vxd_3LUDAKv_mvOSxqI/ link to mail post] * presenter: [mailto:firstname.lastname@example.org Brian Campbell] * time allocated: 25' * objective: get feedback; gauge interest and potentially find an appropriate venue. * specification: https://tools.ietf.org/html/draft-bdc-something-something-certificate-02 Intermediary (cdn, load balncer, etc) terminates TLS. Propose standard way for that entity to pass end-user/client identity on to origin There are other similar solutions (see slides) Mike Bishop: * Q: Support this work; no conflict with Secondary Certificates. Similar to previous presentation's concept! Want to say "this was validated" but not in the way future, but one hop down the line. * A: no response needed, thanks for feedback. Nick Sullivan: * Support this work. Want to implement it. Hasn't been done yet, and fills a need. Mark Nottingham: * Suggest next step: present at HTTPbis. * Getting feedback from CDNs and reverse proxy vendors is what you want. HTTP is a hop-by-hop protocol and you need to take that into account. * A: originally designed to only account for client-to-origin. * In Jabber: discussion of "HTTPbis is doing a lot and there's lots of reverse proxy stuff coming up, does it need to split". mnot: "actually work is dying down, are considering different split" EKR: * Agree that this is an important, and think it needs a lot of coordination with TLS too. Mohit Sethi: * Agree that something like this is needed. Why send entire certificate and not just subject identity? * A: this is pretty much a first draft. Decisions aren't made yet. Certificate made sense to me, don't have to try to pick and choose which bits of data are relevant to the backend application. Doesn't mean it's the final answer. Joe Salowey: * Issues with proxies letting things like this through, and spoofing being possible - a standard might make it easier to test for these and block them. * A: yes, though it might also make it easier for bad guys to know what to attack. Michael Richardson: * Q: Most interesting bit from Jabber - do we need to split out a new WG from HTTPbis for reverse proxies? mnot: maybe SECDISPATCH shouldn't be deciding HTTPBIS's scope! Conclusion: Conversation in HTTPbis (keep TLSWG involved). There's interest in addressing this. == 4. Adding SASL to HTTP == [https://mailarchive.ietf.org/arch/msg/secdispatch/1HJnsIBVTPzdIo6rQ_Oz8-NtBdU/ link to mail post] * presenter: [mailto:email@example.com Rick van Rein] * time allocated: 25' * objective: find an appropriate venue to progress the work * specification: https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-04 ekr via Jabber: so this is SASL? that's what the draft title says "SASL & HTTP" Compared to SAML or Kerberos, SASL is simpler and has more choice (layered on top) HTTP doesn't do SASL; presented some SASL message flows including SASL crossover KRB-based realm cross-over Mark Nottingham: * had a discussion with HTTPBIS/etc - have scheduled for this to be presented to HTTPBIS community at the next meeting. Roman (as AD): * Interested in hearing what implementer interest there is to decide what to do next. Rick: * Obviously we're implementing - what else do you mean. Mark Nottingham: * If it's just server headers then not such a big deal but if it needs coordination then we want an idea of whether CDNs etc will do it. Rick: * In these designs try to get away from applications performing authentication - want to push to a lower layer. * Would like same auth mechanism across all the protocols. Web different from all other protocols. EKR: * == 3. Indicators of Compromise (IoC) and Their Role in Attack Defence == no mail (order switched due to audio issues) * presenter: [mailto:Kirsty.firstname.lastname@example.org Kirsty Paine] * time allocated: 25' * objective: knowledge sharing with IETF on some of the places where cyber defence interacts with its work * specification: https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-00 IOC's are commonly used; goal is to share knowledge with protocol engineers (and prevent them from being accidentally ignored) Draft isn't defining a protocol It's artifacts of information about attacks, used by defense "It is notoriously hard to bring new work to the IETF" the goal is to help protocol engineers learn/leverage IOCs Benefit of publishing as an RFC: * Some are directly relevant to IETF, e.g. protocol artifacts. * Useful to have it in one place * Available in a format that's familiar to protocol engineers * In a venue where people might reasonably see it Why not ISE: * Could see it evolving based on input from IETF. Kathleen Moriarty: * Q: Do you plan to evolve this beyond a summary? Evolve into how to put it into protcols. * A: Feedback is "it's a good summary, there's space to go into more specifics" Ben Kaduk: * There are several different directions this could go in (the document) as well as different potential homes. Not sure which is best. Frame as introduction/tutorial? * need input from people who are willing to put time into helping to shape the document to find a good home. Rich Salz via Jabber: * Is it because it will bring value to the IETF, or because it has a good reputation for publishing. * A: IETF is notoriously hard to publish, it's to bring value. Mark McFadden: * Thinks OPSEC might be a good place for it. The work is interesting. * We do produce documents which provide information about operational experience, and that's what this really is. Roman Danyliw: * OPSEC and MILE are both good. MILE has (...) Ben Schwartz: * Current draft would struggle to get consensus because it conflicts with other work. Could go to independent stream. Kirsty: * Hear the concerns - this is a 00 and it's informational "this is how things are used, and they have benefits". Prevent techniques being ignored. Alissa Cooper: * On that point of "prevent techniques being accidentally ignored" - just publishing a document doesn't do that, you need follow-on that's normative. * A: it's good to have information available, don't expect follow-on documents. Stephen Farrell from Jabber: think this is ISE. ADs? Roman: * Comes down to where the authors want to take it. Welcome further community discussion. * Recommend more feedback from the community and evolve the draft a few more revisions. Discussion on SAAG mailing list? Or MILE and OPSEC. Kritsy: * Thanks, will start on MILE and OPSEC. Conclusion: will work with mile and opsec and update SAAG at some point. 4. Chair summary/session results readout (10 minutes) SVT: AD set up a mailing list and start discussion there, possibly followed by BOF. Client-Cert: -> HTTPBIS start discussion, seeing how it goes possibly consider a wg focused on backend stuff. SASL: -> no actions, already planned to have the discussion in HTTPbis. IOC and attack defence: -> start discussion in MILE and OPSEC mailing lists.