Hi Wes,
On 12/04/2013 05:41 AM, Wesley Eddy wrote:
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.
That's a fair comment, and there are at least two ways one could
have gone about documenting the consensus - the "bare" approach
taken in this draft or one where we included many more details
of the threat and mitigations.
The reasons why we took the current approach are:
- we think there's value in documenting the most-significant bit
of the consensus and I would assert that that can usefully be
cited, but yes, its not a guidebook for protocol designers
- if we want this to be a useful BCP for say the next decade
and beyond (thinking about 3365 for example) then the nature
of the threats and mitigations will change significantly
in that period (or maybe sooner, depending on what's in
tomorrow's Guardian:-), so there could be a downside in being
more specific
- we have folks working to document the threat model separately
in a way that is aimed to be usable for protocol designers
and I think that'll cite this and is maybe part of more what
you were thinking of; similarly, we're looking for folks to
e.g. help document how to do opportunistic encryption or
the like as a tool that can be used, but I think both of
those and other things such as TLS BCPs will be better
processed separately, from this
- there's sooo much potential to bikeshed on every additional
bit of text;-)
So, the draft and my responses below are offered in that context.
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
That could be done, but as I said above I'd be worried that
it mightn't be that useful, if taken too literally and might
cause some lovely bikeshedding.
- examples of instances and general cases where incorporating
mitigations is not a concern
Hmm. Trickier. See below.
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.
Personally, I think its important that we not have this BCP have
a massive get-out-of-jail clause that effectively neuters the
impact we want it to have. And I'd be worried that the kind of
text you're implying might have that effect. (Or did you mean
something else?)
But I do think this is an important discussion for the IETF LC.
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?
I don't think this would affect MPLS extensions. (Although I
did ask about that for the last one that went by the IESG:-)
I'd love to see some more security mechanisms defined for MPLS.
It'd be even better if those were likely to be defined.
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.
Both, IMO. But in many (though not all) cases our specs are
silent about what has to be logged.
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.
Thanks for the thoughtful comments,
S.