Hi all, Here's what I took from the meeting notes and having listened back to the recording. Overall, there was a good bit more here that was concrete than I thought was the case on the day, so thanks all for that!
I put the most vague first and the most concrete last. Apologies in advance if I've annoyed you for how I've characterised your valuable input:-) As always, comments, discussion, volunteering are as welcome as ever! Please start separate threads though unless your follow-up is about the synopsis itself. General thoughts/recommendations, some almost platitudinal: - there's a tension between n/w mgmt & confid - make middleboxes explicit - write more code, connect with OSS communities - think about how our code is implemented/operated, e.g. UPnP - embedded ecosystem doesn't have updates, freezes in bugs, prevents deploying e.g. IPv6 - sometimes we get it wrong when we add too much security - e.g SIP wouldn't have been successful if we'd done security "right" - successful crypto happens where the client just does it and doesn't have to ask, don't sacrifice usability - better documented protocols have fewer security problems - some protocols can't really be secured (e.g. DHCP) so shouldn't be used for lots of config stuff - IPv6 + IPsec + RFC 6092 => IKE, ESP get in, could make things better? - NAT is terrible:-) Research topics, maybe for IAB w/s or IRTF?: - it'd be good to have privacy metrics - think through consequences of mitigations, there will be some - if we get to OE, then how do we get from there to authentication when we want authentication - problems handling security protocol failures (e.g. cert expiry) Review stuff, hard to see such boring work being done: - review old mouldy stuff (even in new docs), incl crypto uses - e2e - maybe a survey of landscape is needed first? - go look at why are existing protocols not being deployed? - organised effort to privacy review existing protocols (directorate?) Actionable maybe, nothing done yet: - either find usable security folks to get involved or else make sure there's no UI, don't require large scale key mgmt - maybe get servers (web) and CA people together to try develop some usable certification protocols - same as above for DNS zone signing tools - IETF should go beyond legislative definitions of personal data e.g. meta-data, define PII as privacy impacting information - should we revise some security BCPs? which? how? who? - (plenary) we should set the GAAP equivalent for security and privacy Lots about OE, but quite actionable: - define OE and how to do it - SF has asked someone if they'd write a HOWTO-pimp-my-protocol-with-OE draft, define it better and how to use it, and be careful with naming it to not imply you get more than you actually get - OE: don't forget active attacks, they can also be somewhat pervasive - OE: don't forget active attacks, they are worse attacks - OE: don't forget active attacks, OE could be oversold - OE: don't forget active attacks, they are more expensive and easier to detect - OE: don't forget active attacks, cost increase may not be as good as you think, e.g. MITM to gather call records - OE: don't forget active attacks, include ways to auto detect them (maybe after the fact) Specific enough to have been actioned already:-) - consider traffic analysis as part of protocol design (-> threat model?, asked Brian) - define a "strong" RNG - a list has been setup for this that's, [email protected] and has been announced - reform privacy directive (asked, got 3-4 interested so far, not enough) if it happens, rfc6973 might help this time = got mail so far from: Scott Brim, Jim Fenton, Rhys Smith, Klass Wierenga more welcome = maybe include more, e.g. "privdir" review to be done when appsawg "adopts" or something? - consider DNS confid, e.g. QNAMEs in DNS queries Bortzmeyer, Koch drafts, discussion with INT and OPS ADs ongoing for where to do that work Regards, S. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
