Re: Last Call: Recognising RFC1984 as a BCP

[Stewart Bryant <[e-mail]>]

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