Subject: [perpass] Fwd: Re: Delivering perpass

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Apr 2014 22:40:24 +0100

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 <[email-masked]>
To: Trevor Freeman <[email-masked]>,  Kathleen Moriarty
<[email-masked]>

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?

---

From: Douglas Otis <[email-masked]>
Date: Sat, 12 Apr 2014 23:33:53 -0700

> (with permission) in case it is.

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

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass