# Security Area Open Meeting (SAAG) - IETF 105 * Thursday July 25, 2019 * Chairs: Ben Kaduk and Roman Danyliw * Minute taker: Rich Salz ## WG/BoF Reports and Administrivia * [Slides and Pointers to Activity Reports](https://datatracker.ietf.org/meeting/105/materials/slides-105-saag-chairs-materials) Additional WG/BoF/Activity Reports: * Elliot Leer: OPSAWG is working on "MUD phone home" * Wendy Seltzer, points to W3C security and privacy activity, including a presentation to PEARG * Dave Thaler: TEEP WG taking a dependency on the SUIT and RATS WGs now * Dave Thaler: ITU-T SG17 work on IoT security, Liaison with SUIT [misspoke at mic, I co-chair both, I meant SUIT] and overlapping participants * Linda Dunbar: IDR is looking at configuring IPsec/IKE; IPsecME didn't know, they had a joint meeting, it went well * Rich Salz: See [draft-ietf-netconf-crypto-types-10](https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-10). It is very bad * Yoav Nir: LAKE had some enthusiasm, AD's figuring out next step since scope is not yet nailed down. ### Privacy Issues in Identifier Locator Separation Protocols * presenter: Dirk von Hugo * [Slides](https://datatracker.ietf.org/meeting/105/materials/slides-105-saag-privacy-issues-in-identifier-locator-seperation-protocols) Comments/Discussion/Feedback: * Eric Rescorla: Are the problems you identified solvable? -- See pg11 * Tim Shepherd: You didn't mention HIP and its ephemeral identifiers, might be worth looking at * Ran Atkinson: RFC 4941 (IP privacy) techniques could be used * Bob Moskowitz: HIP concepts could be helpful; I lurk over there. Will post a comment there. * Robin Wilton: glad to see privacy high on the list, degrees of solutions are worth considering * Hannes Tschofenig: Where is this being used in IoT? -- there's some text in the draft referencing this use case * Bob Moskowitz: how do you deal with other long-lived data (port, etc); still work to be done * Dino Farinacci: encrypt the fields for privacy (Editor note: Discussion on this topic can continue on the [pidloc mailing list](https://www.ietf.org/mailman/listinfo/pidloc)) ### Do we need an expanded Internet Threat Model * presenters: Stephen Farrell * drafts: [draft-arkko-arch-internet-threat-model-01](https://tools.ietf.org/html/draft-arkko-arch-internet-threat-model-01) and [draft-farrell-etm-02](https://tools.ietf.org/html/draft-farrell-etm-02) Comments/Discussion/Feedback: * Mohit Sethi: Yes this is useful, as engineers we need to think about this kind of compromise * Dominique Lazanski: This is extremely relevant * Dave Thaler: I'm interested; RATS and TEEP are designed for environments where end-points aren't fully trusted (Thing2 in the slides) RATS is about attestation, TEEP is about remediation of that. * ? : I am surprised to see this; did we move to communication post-snowden, losing sight of this? * Jeffrey Yaskin: I will join the list; this would have been helpful to my work. W3C probably has interesting things to say about privacy * Ali Rezaki: important to get definitions and use-cases right; I look forward to working on this. * Harald: talk to folks outside the IETF * Eric Rescorla: If you build a protocol, and you have to assume the other side is compromised, you are in very bad shape * David Waltemire: not something we can solve with one protocol * ?: This work should progress somewhere. Is this the right model to use? Draft makes a good point on social attacks. * Eliot Lear: Time to do something with 3552? What formalisms (e.g., protocol approaches) do you envision? ** Stephen: Mostly I don't know * Ben Schwartz: Maybe not "need a new threat model" but "have a a new threat model" is a better title * Lawrence Lundblade: You can look at attestation [???] * Daniel Kahn Gilmore: Linkability is important * Bret Jordan: important work, even at the end of the day if protocols just discuss risks/risk-management * Ben Kaduk: Consider not completely adversarial relationship * Eric Rescorla: +1 to Kaduk and DKG. Also need to think about aspect of protocols * Wes Hardaker: I miss days when open to port<1024 was secure. We're a long way from that. * Kirsty Paine: There are drafts about classes/taxonomies of end points, it's worth looking at them and not replicating the work. They are called CLESS: Capabilities and Limitations of Endpoint Security Solutions. * Paul Turner: What about if network/protocol is being used to attack the endpoint, is that part of the model? ** Stephen: No. I can write threatening email, but RFC 822 is still valid. * Paul: something to consider is compromised communications * Laurence: protocol/equipment implementation might be separable from the data or updates * David ?: if traffic is encrypted, you can't see what endpoints are sending out * * Kathleen Moriarty: Detection is also important, even if we can't actually protect. Please continue discussion on a planned new mailing list. (Editor note: This new mailing list is [model-t](https://www.iab.org/mailman/listinfo/model-t)) ## Open Mic Nothing discussed