Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscu

On 04/03/2011, at 8:06 PM, Dean Willis wrote:

[snip]

> Every document we now produce has a "Security Considerations". I hereby 
> propose the following extensions to that  section, such that each 
> specification requiring a meaningful Security Considerations section MUST 
> address the following:
>
> 1)  Privacy and Integrity: We believe that intermediaries should be neither 
> able to understand nor alter the transmitted material without the explicit 
> consent and awareness of the users. How are the principles of end-to-end 
> privacy and integrity provided by the specification? Reasonable solutions 
> might include any of our well-documented encryption and signature systems 
> coupled with applicable key management mechanisms. Analysis within the 
> specification should also describe the known limitations of the 
> specification, such as susceptibility to hostile certificate authorities. 
> Further, forthcoming IETF specifications MUST not allow plain-text 
> transmission of anything within any protocol. Sign or cipher (or both, as 
> appropriate) everything, all the time.
Encrypting *everything* means that all communications become exclusively 
two-party, and thus requires that you implicitly trust the party at the other 
end of the connection.

I trust both my government and my ISP much more than I trust many of the Web 
sites that I visit with my browser. 

Privacy researchers (like Balachander Krishnamurthy, who unearthed many of the 
liberties that Web sites take with privacy, leading to the current kerfuffle in 
the FTC and recent action by the EU) won't be able to verify how servers treat 
our data if it's all opaque. I think that's a much worse world than the one we 
live in today.


> 2) Privacy and Obscurity: We believe that observation of a traffic flow pr 
> sequence of traffic flows should reveal as little information about the 
> application or user of the application as possible to an intermediary who 
> observes the traffic without the explicit consent and awareness of the user.  
> In principle, "deep packet inspection" should be completely useless, as 
> should attempts by an intermediary to trace the end-user(s) to a specific 
> physical location. How does the specification provide for obscuring the 
> content of the application and the identity and location of users involved in 
> the sequence?  Reasonable solutions might include things like TOR combined 
> with TLS. Analysis within the specification should also describe known 
> limitations of the specification, such as frequency and time domain analysis 
> at a network-adjacent node, or dependency on interceptible dereferencing 
> mechanisms like the DNS. 
This will have the effect of isolating some companies and countries from the 
Internet. Is that a good outcome?


[snip]

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf