[perpass] Way forward? [Was: Tiny stacks]

[Martin Millnert <[e-mail]>]

On Tue, 2013-12-10 at 08:47 +1300, Brian E Carpenter wrote:
> It seems to me that perpass should think a little bit about
> privacy and anti-surveillance issues for devices with tiny
> stacks, and see if that calls for any specific IETF work items.

I completely agree it's good to understand consequences on security
requirements.  That will probably follow naturally on the other hand,
once said requirements become known.  But what's more important, is what
failure to fulfill the requirements mean.

For example:
Requirements & considerations for mitigating pervasive passive
surveillance are <X>.
Device D or protocol P fulfills 50% of <X>.  Thus, D / P are not [insert
pervasive surveillance-resistant consumer logo here] compliant.

That would be some form of ideal information to possess, allowing
protocols & implementations, etc. to more easily be benchmarked on their
performance of surveillance-resistance.

Divide and conquer.  By enumerating and specifying the threats (on all
stack layers, even if implementation of mitigation is not up to IETF)
and what's generally required to avoid them separately from guidance on
how to avoid them, or guidance for protocol wg's, I believe we can
better avoid the... detours and distractions.

Vendors have been building TLS MITM for enterprises for a long time.
That is not necessarily going to be stopped by always-on-TLS in HTTP
2.0.  That, and how to balance bandwidth saving caching functions with
perpass-resistant protocols, is probably better discussed in their
respective wg's.
  What should be perfectly clear is however, that for example in HTTP
2.0, allowing transparent proxies, will score very, very low on
perpass-resistance.
  That benchmarking feature is IMO useful output from perpass following
draft-farrell-perpass-attack-02, which to me reads completely fine.

My 2c,
Martin