On Sun, Aug 17, 2014 at 9:58 AM, Paul Wouters <paul(_at_)nohats(_dot_)ca> 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
--