On Apr 11, 2014, at 2:40 PM, Stephen Farrell <[email protected]> wrote:
> > 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. Dear Stephen, There is in fact a reasonable email solution with low leakage unlike PGP or S/MIME. See: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07 Regards, Douglas Otis > -------- Original Message -------- > Subject: Re: Delivering perpass > Date: Fri, 11 Apr 2014 13:14:50 +0100 > From: Stephen Farrell <[email protected]> > To: Trevor Freeman <[email protected]>, Kathleen Moriarty > <[email protected]> > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
