ietf
[Top] [All Lists]

Re: Last Call: Recognising RFC1984 as a BCP

2015-08-17 12:16:26
On 8/17/2015 9:50 AM, Stewart Bryant wrote:
On 17/08/2015 17:21, Dave Crocker wrote:
So the goal you are espousing is to globally embed a mechanism for
compromising privacy, in order to catch stupid criminals, knowing that
it will be useless against serious and intelligent criminals?
... serious and intelligent criminals that never make a mistake.
Fortunately
a relatively rare group.

Stewart,

You might want to add 'never' as a qualifier but I will suggest that it
is an irrelevant distraction, mostly serving to try to move the topic to
an ad absurdum requirement for mathematical perfection that is not at
all relevant to real-world, practical concerns here.


... and when you say global,  one not would put in place
a single global repository for any single element of the system.

Wrong focus.  You are proposing modifications to global standards that
will support state-based privacy compromise.  I never said anything
about a single repository.

What I am referring to is a modification to global standards for
privacy, in support of an organized ability to compromise that privacy.


What is needed is to raise the bar to the point where it is difficult
but not impossible for duly authorized access (subject to scrutiny),
but close to the ideal for unauthorized access.

Again, for your overall statement, you have described a research topic,
not a topic ready for standardization by the IETF and frankly, therefore
not ready for support by the IETF.

But to the specific reference to 'scrutiny', it presumes adequacy of a
particular approach using an oversight component, when there is amble
evidence that, to date, such an approach to protection works somewhere
between 'poorly' and 'not at all'.


Your premise that the result would "provide[] satisfactory privacy for
ordinary citizens" is, so far, counterfactual, given the many and
continuing revelations that document state-based compromises.
I am not advocating a system where a state can read stuff at will
which is where we were (are?), but I am concerned that swinging the
pendulum to the point where reading data for what most would
consider legitimate purpose is prevented.

The pendulum swung to that latter capability long ago.  Hence Brian's
point that those who are serious about solid and (essentially)
unbreakable encryption have long had access to it /and will continue to
have access to it, independent of any embedded compromise mechanisms
that we might define/.

Rather, what you are proposing is that we make sure such a capability is
not obtained casually.


Based on experience to date, at best what you propose is an open and
very difficult research topic, at the intersection of computer science,
engineering, operations, politics and sociology.
Yes, it is a hard problem, but that does not make it the less worthwhile.

The IETF should not espouse standardization of capabilities that remain
open and very difficult research problems.  If and when the issue
becomes amenable to large-scale engineering, implementation and
operation across very large numbers of independent administrations and
states, the IETF could reasonably re-visit the topic.

As of now, the most we should say is that it is a research topic and we
do not know how to design it adequately.


The issue here is not a question of a component bit of key distribution
design, but rather of system-level, long-term efficacy in protecting
privacy in the face of sustained compromise efforts by well-funded,
dedicated and highly intelligent adversaries.
There are many parts of the Internet that need to be protected from
such a concerted attack, and with much greater payoff than reading
the traffic of individuals.

Yes, well, that's my point.  I suspect however that I was not clear
enough in my reference.

The attack(s) I am talking about would be from the state agencies
seeking to compromise the purported protections ensuring safety against
misuse of the IETF-created, embedded compromise mechanism.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net