* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Secdispatch Status Pages

Security 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

Minutes

minutes-107-secdispatch-00 minutes



          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:stefan@aaa-sec.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:bcampbell@pingidentity.com 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:rick@openfortress.nl 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.p@ncsc.gov.uk 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.
          
          



Generated from PyHt script /wg/secdispatch/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -