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