Minutes IETF105: saag
minutes-105-saag-00

# 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 *
<missed/elided/quit> * 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