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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
