On Sun, Aug 17, 2014 at 9:58 AM, Paul Wouters <paul@xxxxxxxxx> wrote: > I've actually contributed quite some text for clarifications (see git > history) and I know others have too, despite the paint discussion). > I've also suggested this document brings in mroe technical content helping > protocol designs but to some that seemed out of scope and a matter for > another document. To me, once you remove the sillyness of the terminology, > this document is precisely about giving protocol engineers generic help. The silliness or not of the terminology is bikeshedding about terminology. > Things I came up with that I think belong in this document > > - encrypt as much as possibly as soon as possible. eg no SNI style leaks I agree, though this seems rather generic, not so specific to OS. > - Mandate PFS/session keys protection (Viktor included that in -03) Hmmm. I agree that when opportunistically engaging in unauthenticated encryption key agreement should be used, and public keys should be fresh enough that PFS results. I think that's pretty obvious. But I don't think we should mandate PFS for all OS cases. Again, this seems like a generic recommendation/requirement, not specific to OS. > - Don't ask more identifying data then you need for protocol functioning > (generic privacy/anonimity practises) Agreed. > - Follow RFCs as strict as possible to defeat fingerprinting attacks Agreed, but again: too generic. > - If a connection is one-sided authenticated (eg like TLS) ensure your > protocol is okay with a role-reversal (eg if it needs to authenticate > the end that was anonymous) Ditto. > - Ensure crypto agility doesn't come at the cost of more RTTs when the > world moves to something stronger (eg the IKE modp problem) Ditto. I don't think this I-D should become a dumping ground of good security protocol design patterns. It's just one pattern. Nico --