Skip to main content

Minutes IETF107: secdispatch
minutes-107-secdispatch-00

Meeting Minutes Security Dispatch (secdispatch) WG
Date and time 2020-03-27 20:00
Title Minutes IETF107: secdispatch
State Active
Other versions plain text
Last updated 2020-04-01

minutes-107-secdispatch-00
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.