SAAG and Secdispatch @ IETF112

Tuesday, November 9, 2021, 12:00-14:00 UTC
SAAG chairs/security ADs: Roman Danyliw, Benjamin Kaduk
Secdispatch Chairs: Kathleen Moriarty, Richard Barnes, Mohit Sethi

Original at: https://notes.ietf.org/notes-ietf-112-secdispatch#
Jabber: xmpp:secdispatch@jabber.ietf.org
Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=secdispatch&short=&item=1

Agenda

Introduction (ADs) - 10 minutes

slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-secdispatch-saag-session-1-chairs-slides-01

Update on NIST PQC Project (Dustin Moody)

slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-secdispatch-saag-session-1-update-on-nist-pqc-project-01

SAAG Open Mic

SECDISPATCH

Draft on secure credential transfer: https://datatracker.ietf.org/doc/draft-secure-credential-transfer/ BOF next IETF. Resolved on mailing list

Agenda Bash

Tommy Pauly (TP) - Spend a little more time on each talk.
Mohit Sethi (MS) - Sure

Private Access Tokens (draft-private-access-tokens) - 30 minutes

Link to draft: https://datatracker.ietf.org/doc/html/draft-private-access-tokens-00
Link to post on mailing list: https://mailarchive.ietf.org/arch/msg/secdispatch/ABhJrIZcXtFw2TL_kjm9jFoibck/
Tommy Pauly presenting:

(PHB): Verisign has a patent that is similar from 2003 (USPT 7,676,546). I thought that PoW was a terrible idea (then and now). We considered doing this in a trusted module on the device. The only value that Verisign could get out of this at the moment would be to make an agreement between Google and Apple as they control the silicon. The reason that it didn’t happen then is because there was an ever older patent. The mediator could be on the device.

Ben Schwartz (Chair of PP): I think this work is appropriate for the PPWG. I don’t think there is any presumption that we would take this work as is and adopt it, but I do think the use cases are important. I don’t think we should forge ahead with this and PP in parallel. We should find one solution to pursue first (at least), and then roll it out, get some experience with it, before rolling out something with the same ingredients.

(TP): Chris Wood (CW) and (??) both were thinking about mixed types of tokens.
Ben: Need discovery, unified privacy analysis, etc. All reasons. (Takes off hat) Not as compelling. Lean toward computational not information theoretic privacy. Huge number of issuers back into leaking one bit for every issuer present or not.

– Queue cut–

(TP) I agree that it’s desirable to have something simple wit hismple trust relationships. The issue with PP is that it provides so little information that it can’t service a lot of the use cases.

Shivan Sahib (SS): dalek noises Presentation was about PP ratelimiting but draft also talks about geolocation. Is there a reason for that? Centralisation concerns of mediators especially should be discussed in the draft.

(TP): To limit the complexity of the presentation. Yes, we should discuss centralisation concerns in the draft.

Ekr: This and PP together is bad news. We need to clarify use cases, bar the rate-limiting use case (which is client specific and origin specific), all the other use cases are client specific but not origin specific, so can be solved by PP. We should consider whether the use-cases are important.

Andrew Campling (AC): Needs to address how to avoid the problem of colluding mediators and issuers. If not addressed the benefits are completely illusory. (Agree with PHB PoW is bad.) Dispatch to PP. Maybe look at in depth in PP, then come back to dispatch.

Roman Danyliw (RD): Send to PrivacyPass (PP) WG. The experise to evaluate the next steps will be there. Many options to include informing PP work (e.g., with use cases), rechartering or rescoping PP (given interest), or returning here if there isn’t alignment with PP.
Dispatch Decision: to PP

Security and Privacy Considerations for Multicast Transports (draft-krose-multicast-security) - 30 minutes

Link to draft: https://datatracker.ietf.org/doc/html/draft-krose-multicast-security-01
Link to post on mailing list: https://mailarchive.ietf.org/arch/msg/secdispatch/N1jDh7MRHupuPIf1S5BiLDecGGY/
Jake Holland (JH) presenting:

(BK): Is your key question “Is there a security model we can use here?”?

(JH): There is lots of non-Browser traffic that uses broadcast now, so we’d like to address this in a generic way. Web isn’t necc. the starting point, but we want to get there eventually.

Ekr: I’m not sure your problem is what you think it is. There are 2 security models:

  1. FETCH / the origin model
  2. WebRTC/webtransport

No way to map into 1, 2 is likely the place to map into. Think this is not for the IETF, security properties not complex, web is the problem. Not sure what to do

(JH): Chromium is sceptical probably because they don’t think it will work. I don’t think this is as out of reach as people think it is.

(WL): Not clear what’s needed: does W3C have clear idea, or does this need to be worked out here.

(JH): We think the draft we proposed presents a reasonable model. The W3C’s feedback is that we need to work on the underlying security model.

(BS): This piece of work is too big to do all out once. Solve the protocol problem and then the broswer problem. Dispatch to CDNI and treat this as a CDN-CDN protocol, and then work on bringing the box closer and closer to the client.

(JH): Don’t think this is viable. We have that part solved.

Dispatch Decision: Discuss on a mailing list. Which one? author+AD choice

Recaping:
PATS to PP, PP to decide what to do, recharter or kick back
This draft to the list.
No extra time thursday