Before we get into the broader definition of trust and all kinds of possible threats, I'd like to make sure the scope of this document is understood. I apologize if that was not clear from my first email or the draft itself.
This document covers the case where a client and server wish to exchange traffic over a channel that is either end-to-end secure or is point-to-point secured to an authorized middle box. The threats it addresses are those due to unauthorized middle boxes and provides guidelines and goals to make those detectable by the endpoints, including the user. It is not intended to tackle the general case of rogue servers or the generic case of placing all privacy controls with the user. It is not to say that such goals aren't necessary for the Internet - just that this document is written to explicitly handle only a subset as mentioned above. Hope this helps. Thanks, Vidya On Wed, Oct 30, 2013 at 2:39 PM, JOSEFSSON Erik < [email protected]> wrote: > Here's a woman I trust on trust: > > > http://www.ted.com/talks/onora_o_neill_what_we_don_t_understand_about_trust.html > > //Erik > ________________________________________ > From: [email protected] [[email protected]] on behalf of > Hannes Tschofenig [[email protected]] > Sent: Wednesday, October 30, 2013 9:03 PM > To: Bjoern Hoehrmann > Cc: Vidya Narayanan; [email protected]; [email protected] > Subject: Re: [perpass] Explicit proxying in HTTP > > Hi Vidya, Hi Bjoern, > > the term "trust" is quite tricky. You may trust someone to do X but not > Y. Hence, you have to say what you believe the "client" (user, I guess) > trusts the server for. > > Just think about the concept of 'secondary use'. > > Ciao > Hannes > > > Am 30.10.13 20:40, schrieb Bjoern Hoehrmann: > > * Vidya Narayanan wrote: > >> 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. > > > > You buy a smartphone. You come to suspect it may have a bug that makes > > it send encrypted data over the wire it should not be sending. You con- > > figure a MITM proxy and try to trigger the bug. You detect the phone > > starts sending data to a server, but the server cuts the connection as > > it detects the proxy. > > > > So you cannot verify what the smartphone actually sends, you are not in > > control. "Privacy" and end-to-end security require the user to be in > > control, so that a server "cannot refuse to serve sensitive content over > > a proxied connection" is a good thing, while you list it as a problem. > > My suggestion was to include a Goal to ensure that users are in control. > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
