On Sat, 16 Aug 2014, Nico Williams wrote:
However a quick search on the term produced some troubling existing
usages that conflict with the usage in the draft:
Bikeshedding is what this is.
Except in this day, the bikeshed needn't have a name. Our products are
RFC numbers. As I said before, why define a term that we can't agree on?
Just call this document something like "Defending against pervasive
monitors". Get rid of "OS" and "opportunistic security" and "design
patterns". That's the actual bikeshed paint we don't need.
Another question, even more important, is whether OS (the proposed
protocol design pattern, not the term) is on the right path or whether
it is dangerous, or how to improve it. I've yet to see anargument that
Viktor's OS proposal is weak tea, dangerous, or could be improved, only
lots and lots of verbiage about verbiage.
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.
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
- Mandate PFS/session keys protection (Viktor included that in -03)
- Don't ask more identifying data then you need for protocol functioning
(generic privacy/anonimity practises)
- Follow RFCs as strict as possible to defeat fingerprinting attacks
- 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)
- Ensure crypto agility doesn't come at the cost of more RTTs when the
world moves to something stronger (eg the IKE modp problem)
Paul