Hiya, Trevor was asking me about the state of play here. The answer might be more generally useful so forwarding this (with permission) in case it is.
Cheers, S. -------- Original Message -------- Subject: Re: Delivering perpass Date: Fri, 11 Apr 2014 13:14:50 +0100 From: Stephen Farrell <stephen.farr...@cs.tcd.ie> To: Trevor Freeman <trev...@exchange.microsoft.com>, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> Hi Trevor, On 04/10/2014 10:35 PM, Trevor Freeman wrote: > Hi folks, > > I am curious how you see the perpass discussion changing some of IETF > practices. > > As noted in the perpass attack draft > > Pervasive monitoring is a technical attack that should be mitigated > in the design of IETF protocols, where possible > > How is the "where possible" going to be assessed. Will the > presumption become you must defend against perpass unless you can > show solid reasons why not? For example, requiring authors to > document some possible approaches and why they were eliminated to at > least show they tried? What about the backwards compatibility card, > how often can that be played? The reality is that we'll have to learn as we go. Our new bcp does not say you "must defend against" but rather that you must have considered the topic. The extent to which that gets done well or badly is something we'll have to see, as will the ways that participants, WGs and the IESG deal with that. Please don't though consider this as something the IESG police, it'll be better off all around if participants do consider the PM attack and if WGs take that into account, as per the new BCP. Same as always, factoring stuff like this in early is going to be better and easier all around. Backwards compatibility is clearly an issue but I don't think of it as a card to play, its another engineering constraint that we have to deal with. For example, we are not getting rid of email, and won't even though email is leaky as hell with meta-data even with S/MIME or PGP. If someone did come up with a workable e2e email security solution that was way less leaky and that got deployed, then we would want to consider that, but since that's mythical, it doesn't arise. So absent a working solution, for email, backwards compatibility is likely to be a factor forever. In other cases, YMMV of course but that's just because we're dealing with partly conflicting constraints, as we always do. > > Do we need to go though and audit the existing portfolio to see where > we have work to do to meet the higher standards i.e. perpass > resistant? There's work started to do reviews of old RFCs for this. We'd be delighted if you were to join in on that! Contact Avri Doria or Scott Brim. There's a wiki page at [1] for that. [1] https://trac.tools.ietf.org/group/ppm-legacy-review/ The intent there is that as and when we do new work on those technologies, these reviews can inform that work. And maybe these reviews might motivate folks to do new work as well, we'll see. We're in a try-and-see mode right now, and hope to see how that's going at IETF-90, so your input on that now would be really timely and appreciated if you have a few cycles to pick an RFC, make a ticket and do a review of that in the next month or so. (Go on, I bet you have some RFC you can think of that could be useful low-hanging fruit for this:-) > > Do we need a new guidance rfc to lay out the priorities for > confidentially, integrity and authentication security for rfc > authors? Yes we do. But we're not ready for that yet. The idea I think would be to add a new RFC to BCP 72 [2] that sets out what we've learned, once we've learned enough. I'd hope that we might be able to start on that towards the end of the year. (And again, feel free to volunteer in advance to help out:-) [2] https://tools.ietf.org/html/bcp72 We also want to get the threat model draft [3] done so consider helping out there too if you've time with comments/text etc as usual. [3] https://tools.ietf.org/html/draft-barnes-pervasive-problem > > The standards we write can be used both on-premise and in the cloud. > Pervasive monitoring is a bigger priority for cloud deployments. How > should we reconcile those two scenarios since they are deployment > specific. Yes, that tension is noted in pepass-attack and will be part of the working-out that we work out. There's also however the fact that while many deployments previously considered protocols to be running in "trusted" environments, we have seen (e.g. Belgacom) that that is not such a good assumption any more given the PM attack. That has already had clear impact for e.g. inter data centre traffic deployments, but will take longer to work out for e.g. Diameter deployments I expect. But in both cases the change is not so much to the protocol but to turn on security. > I am sure you and your colleges on the IESG have been mulling over > similar questions. Yep. We're discussing some modification to the discuss criteria [4] in the short term, and will have a broader discussion at the IESG retreat in May. Jari posted about the discuss criteria change plan to the IETF list before, but we're wrangling text at the moment. Anything longer term, will be reported as usual and the community will get their say as usual. [4] https://www.ietf.org/iesg/statement/discuss-criteria.html > I was just curious what might be written on the new stones when you > come back down the mountain. Thanks Trevor There's no mountain and no stones:-) The perpass-attack LC for example had nearly 1000 messages on various lists and the Vancouver tech plenary had I'd say about 1000 people in the room. The IESG are not aiming to surprise anyone on this, but to reflect the IETF consensus, which is rough, but which I hope will get less rough as we go and as folks see that we're improving things without going crazy. Cheers, S. PS: Now that I've written this, it might be a useful state-of-play to send to the perpass list, mind if I do that by just forwarding this? > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
