|
Eliot's two quotes nicely illustrate
the dilemma of perfect encryption.
As engineers we should aim to address this dilemma rather than
simply declare it impossible, and opt for data privacy at all
costs.
We have a social responsibility to design an internet that is
rugged
from attack, that is fit for use by law-abiding people but does
not
provide an impregnable conduit for the use of people that seek to
harm us.
My concern is that by elevating the status of RFC1984 we fail to
acknowledge the dilemma, and do not set a goal of designing
technologies that allow the internet to be used to reliably and
safely carry information for the law abiding, but still provide
the ability for those that we trust to protect us from harm
to perform that task.
- Stewart
On 12/08/2015 21:55, Eliot Lear wrote:
Hi,
On 8/12/15 10:21 PM, Roy T. Fielding
wrote:
I think you completely missed my point. The
document says it is an opinion piece by the IAB and IESG.
Everything in it is phrased as such to avoid pissing off the
people in the IETF who believe the institution should not be
playing politics. The result is fine in the context of an
informational RFC. It is not fine for a BCP, even if that
document is brought to the IESG with full consensus of all
working groups.
This is not simply politics, although we cannot deny that there
are some. But to put it only in those terms demonstrates a
misunderstanding of RFC 1984. The document represents what was
and is, I believe, a strong consensus view that key escrow, key
length limitations, and export restrictions are technically
harmful to Internet users for all the reasons stated in the
draft. The points made in the draft were technically indisputable
then and are indisputable now. If we had to open up 1984 we
simply wouldn't change much, but we would make it a BCP.
So why not just do so?
BTW, I think the choice of 1984 as an RFC number
was atypically juvenile. I don't think anyone outside the
echo-chamber has taken RFC1984 seriously, regardless of its
status; instead, the opinions it described have been adopted
because the alternatives it argues against are inherently
stupid. ....Roy
That didn't stop governments from imposing export restrictions or
proposing key escrow and other bad ideas. That we are here again
now is disheartening.
But I'll say one more thing about this: there is, I think, value
in delving into the substance of the law enforcement is raising.
Today there was an editorial by Cyrus Vance, Jr. amongst others in
the New York Times that called out Apple and Google on their
approach.[1] Last week there was an article in that same paper
about how wiretapping brought down a huge scam at Brazilian oil
producer Petrobras.[2] Applying the sound logic of 1984 to these
new examples probably would be very helpful. In addition, there
have been massive security failures involving escrowed keys.
Highlighting that would also be helpful. All of these points
would emphasize just how timeless RFC 1984 truly is, and so should
be recognized as a BCP. Doing so may also facilitate a very much
needed dialog between law enforcement and the technical community.
As to any process issues, we have the ability as a community to
make exceptions, if we believe a process exception is needed.
Rough consensus gives us that freedom.
Eliot
[1]
http://www.nytimes.com/2015/08/12/opinion/apple-google-when-phone-encryption-blocks-justice.html
[2]
http://www.nytimes.com/2015/08/09/business/international/effects-of-petrobras-scandal-leave-brazilians-lamenting-a-lost-dream.html
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
|