Dear Vidya, IMHO, the basic problem is making security related decisions using untrustworthy input. Users subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial levels of risk. Joe St Sauver offered a pointer to Terry Zink's transitional theory for IPv6 where email needs to make rejection decisions at the beginning of an exchange. See: http://blogs.msdn.com/b/tzink/archive/2013/09/11/supporting-email-over-ipv6-part-1-an-introduction.aspx
While agreeing fully with Terry's basic assertion about this basic need, SMTP lacks expedient methods to confirm source identities such as a domain. He suggests whitelists can be compiled based upon confirmations related to DKIM or SPF. Ironically, DKIM does not validate domains initiating an exchange, and SPF depends upon a macro language able to cause hundreds of DNS transactions based on highly variable message elements with potentially nefarious aim. Decisions based on untrustworthy input while using dangerous protocols makes it absurd to suggest other approaches come any where close to offering the same level of risk! Generating a whitelist using untrustworthy input is doomed to confront the age old problem of garbage-in garbage-out. If you configure your browser to require valid certificates and find you are able to access your bank, one might hope a proxy modified transaction could not be completed. Unfortunately, that is not always the case. L2TP/IPsec http://tools.ietf.org/html/rfc3193 connecting to a known safe environment seems like a better solution. When this type of VPN is blocked, the user should not have an expectation of privacy. It would have been nice to find this protocol not borked by an OS update. :^( Regards, Douglas Otis On Oct 30, 2013, at 11:09 AM, Vidya Narayanan <[email protected]> wrote: > Hi, > I may be missing something here, but your wording seems to suggest that the > user may not trust the server? If so, that is definitely not the targeted > case under discussion. The assumption here is that the client (and hence the > user) and the server trust each other, but they don't necessarily trust all > middleboxes. > > If I have not understood you correctly, please let me know. > > Regards, > Vidya > > > On Tue, Oct 29, 2013 at 6:51 AM, Bjoern Hoehrmann <[email protected]> wrote: > * Vidya Narayanan wrote: > >All, > >http://tools.ietf.org/id/draft-vidya-httpbis-explicit-proxy-ps-00.txt is a > >problem statement on the need for explicit proxying in HTTP. > > I have a suggestion. From the document: > > The use of proxies leads to a number of privacy issues. To > summarize: > > ... > > o The server has no knowledge of the presence of the proxy and > hence, cannot refuse to serve sensitive content over a proxied > connection. > > o The weakened security model, when certificate pinning is disabled > at a general level, allows inspection of content ... > > ... > > With privacy becoming more and more important, it is important for us > to support solutions that allow awareness of a privacy breach to both > users and the servers, when that happens. To this effect, it is > important that proxies be explicitly supported and detected. > > ... > > o Content providers may not wish to serve certain content in > anything less than an end-to-end secure fashion. > > How about including in the Goals section that users must be able to > verify the behavior of untrusted user agents without interference on > part of the server, which requires the user being able to inspect any > content without the server knowing, possibly by use of a proxy? > > I also note that allowing servers to be aware when my "privacy" has > been "breached" in all likelyhood makes that breach worse, not better. > -- > Björn Höhrmann · mailto:[email protected] · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
