On 12/12/2013 01:56 AM, Bjoern Hoehrmann wrote:
I am not sure what to make of your comments here. Perhaps an example
might help, http://edition.cnn.com/2010/CRIME/12/08/wikileaks.students/
U.S. agencies have warned some employees that reading the classified
State Department documents released by WikiLeaks puts them at risk of
losing their jobs. But what about students considering jobs with the
federal government? Do they jeopardize their chances by reading
WikiLeaks?
If surveillance is pervasive, then students must assume someone will
know which sites they visit and assume there will be repercussions. So
they are forced into a constant state of fear where they need to care-
fully consider, say, which headlines on a newspaper website they click.
If your draft is not about removing this fear, then I do not know what
it might be about. If it is, then it would seem to call for "ubiquitous
confidentiality" unless you are making a very fine point.
WRT the fear - what Brian said. He put it better than I
would have.
As to the question of "what's it about that's not ubiquitous
confidentiality":
There are many other techniques that will be relevant in the end
I'd say. For example, over time, I'd hope that we end up with
fewer protocols that provide uncontrollable opportunities for
tracking. That will require application protocol design
considerations that don't involve crypto.
Some protocol designers will I would hope require fewer long
term identifiers to be visible to many entities, for example
some values only needed hop-by-hop could change so as not to
be the same end-to-end. I'm thinking of how the X-Forwarded-For
that became the standards track HTTP Forwarded header field
could have been done better had privacy been a serious
requirement. Maybe some hash function would have been a part
of a better solution there, or maybe obfuscation, but
confidentiality would not have been relevant in doing that
work.
For DNS, we've seen a proposal to not send the full QNAME in
all queries as those are sent up towards the root. No crypto,
since it just involves sending less stuff, but a possibly
nice (though not problem-free) mitigation.
Perhaps CGAs will become more popular - those do involve crypto
but no confidentiality.
Speculating - perhaps people will find better ways to manage
networks without recording (bytes from) every packet or flow.
If sampling and statistical methods can meet the requirements
without being so close to pervasive monitoring then that might
make for a privacy-friendly IPFIX profile for example.
Yes, confidentiality provided via crypto will be a part of some
protocol design work. But far from all of it. And for many protocol
designers, if they can easily layer on top of TLS or IPsec then
that'll be the right choice and those protocol designers won't
be doing crypto protocol design. (Thankfully:-)
Certificate Transparency is another potential part of some
mitigations for pervasive monitoring, and while that might be
a user of a confidentiality service, it doesn't provide one.
And so on.
And there will be cases where we've no good mitigations to
offer: I've no idea how one might run DHCP with crypto based
confidentiality, nor even practical e2e email security as
I mentioned before. There'll be loads of protocols where
we just don't have a workable confidentiality service and
we'll live with that.
So yes, we've a wait on our hands before we get perfection.
Please don't hold your breath:-)
And what the 106-email-but-inconclusive "https at ietf.org"
discussion does show up is that there are still some arguments
for making some information available in clear. (I'm not saying
what I think is the right conclusion of that argument.) This
draft doesn't claim to judge the best outcome for that discussion,
it just says that the discussion needs to be given proper (and
not perfunctory) consideration. Its sort of optimistic in that
respect and assumes that if the IETF do properly consider
something then we tend to have a hard time denying e.g. laws
of physics:-) I guess the biggest stick embedded in the draft
is that if some WG demonstrably don't tackle the issue where
some obvious mitigation exists, then that WG should experience
unhappiness.
And even with all that, this draft does not actually call for
any security mechanism to be more-than-MTI, where MTI means
mandatory to implement which has been the IETF's consensus
position on strong security mechanisms for over a decade [1].
So there's no process innovation here and confidentiality is
just one tool in a toolbox that I hope we start filling up
some more. And I figure this BCP can help there to really get
better technical outcomes, and without being at all onerous.
I don't think its quite a no-brainer, but for anyone who's
thought the issues through, it should appear to be a
no-brainer.
Hence my question as to the (ir)relevance of John's comment.
But having said all that, would I personally like it if the
IETF did reach a consensus position that everything possible
MUST be encrypted by default? I probably would. But that's a
separate day's work and is not called for by this draft no
matter how many times people mis-represent the draft as saying
that it does.
Hope that helps,
S.
[1] http://tools.ietf.org/html/rfc3365