On 12/3/2013 11:45 PM, Jari Arkko wrote: > I wanted to draw your attention on this last call: > >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Pervasive Monitoring is an Attack' >> <draft-farrell-perpass-attack-02.txt> as Best Current Practice >> >> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ > > > It is a short read and important, so please comment. The last call ends in four weeks and covers holiday time, but we'll deal with this document on the January 9th telechat in the IESG, so in practice there should be enough time to comment. > > I would like to see this document as a high-level policy we have on dealing with this particular type of vulnerabilities in the Internet. A little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong security. Please remember that the details and tradeoffs for specific solutions are for our WGs to consider and not spelled out here. The draft does say "where possible" - I do not want to give the impression that our technology can either fully prevent all vulnerabilities or do it in all situations. There are obviously aspects that do not relate to communications security (like access to content by your peer) and there are many practical considerations that may not make it possible to provide additional privacy protection even when we are talking about the communications part. But I do believe we need to consider these vulnerabilities and do our best. It is good to have the consensus recorded in a document like this, but I think the current draft is too vague to be usefully cited and not just abused as a club against ourselves in the future. If it's worth making a BCP on this, then it's worth beefing up to be more specific about what it means and what context it's coming from. I believe it should have at least a couple clear examples of: - mechanisms that have been (or can be) used as mitigations - examples of instances and general cases where incorporating mitigations is not a concern I suggest both of these because I don't want to imagine many reviews later on that say "you forgot to deal with pervasive monitoring in the $FOO protocol", when there may not even be good technical mechanisms available to deal with it, and/or it may not even be applicable for the $FOO protocol. For instance, this BCP shouldn't be able to be misinterpreted to imply that all protocols need to implement their own crypto, nor that they have mandatory incorporation of TLS, or anything like that. The "where possible" in the abstract and 2nd paragraph of section 2, should be more like "where it is possible, important for the use cases of the protocol, and reasonable to implement and operate such mechanisms". The simple "where possible" doesn't seem like much of a limitation or escape clause to me ... just about anything is _possible_, but it may not always make sense. As an example, would we expect MPLS to do anything about pervasive monitoring or can new MPLS extensions keep moving through the IETF without heeding to this BCP? It's also not clear to me whether it's intended to only apply to protocol behavior "on the wire" or also to logging behaviors, log formats, and other privacy-defeating factors of implementations. It specifically says that this is about privacy, and that requires a lot more than just wire protocol work in order to create. I think it would be good to mention these aspects, if this as a BCP will really be referenced by the community in the future. -- Wes Eddy MTI Systems