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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]