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
(John Mattson) How many changes are coming?
** A: Typicaly on minor changes; no major redesigns
(Watson Ladd) There was a long gap with EC deployment due to IPR and performance concerns. Are NIST’s recommendations going to consider this?
** A: NIST is going to continue on after Round 3 and considering additional research to be responsive
(Phillip Hallam-Baker) Could any of these algorithms be adapted to threshold approaches?
** A: This would be future work. Some of the existing candidates could be suitable, but there has been little analysis.
(Eric Rescorla) Can you say a bit more about KEMs?
** A: At the onset we looked at DH replacements but nothing came in during R1. There is not focus on this right now.
(Stephen Farrell) Encumbered algorithms are a problem. I hope there won’t be a number of options to choose from since this complicates standardization.
** A: Yes, We recognize this issue and have heard it from industry.
(Benjamin Schwartz) Have you looked at hybrid approaches with Merkle …
** A: Yes, we are aware of the research in batch signing. It is a consideration.
(Ben Kaduk) Can you say a bit more about the expected key size expansion?
** A: The candidates are likely around a thousand bytes (at a minimum) for category 1 coming out of Round 1.
(Mike Ounsworth) At the Florida workshop, there was an idea to consider hybrid scheme …
** A: Unaware if there was follow-on work
Draft on secure credential transfer: https://datatracker.ietf.org/doc/draft-secure-credential-transfer/ BOF next IETF. Resolved on mailing list
Tommy Pauly (TP) - Spend a little more time on each talk.
Mohit Sethi (MS) - Sure
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
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:
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