Subject: [perpass] Explicit proxying in HTTP

From: Vidya Narayanan <[email-masked]>
Date: Mon, 28 Oct 2013 13:19:21 -0700

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.  This is an
FYI for this group at the moment and it is a topic expected to be discussed
in the HTTPbis working group.  However, since it also relates to the
mission of the perpass list, I am sending a pointer.  I will not be at
Vancouver - however, my colleague, Ted Hardie has kindly volunteered to be
engaged in discussions on this topic, should there be any questions.

Abstract

   This document describes the issues with HTTP proxies for TLS
   protected traffic and motivates the need for explicit proxying
   capability in HTTP.  It also presents the goals that such a solution
   would need to satisfy and some example solution directions.

Best,
Vidya

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 29 Oct 2013 14:51:58 +0100

* Vidya Narayanan wrote:
>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-masked] · 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/

---

From: Vidya Narayanan <[email-masked]>
Date: Wed, 30 Oct 2013 11:09:16 -0700

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 30 Oct 2013 20:40:02 +0100

>the user) and the server trust each other, but they don't necessarily trust

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.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Oct 2013 21:03:40 +0100

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

---

From: JOSEFSSON Erik <[email-masked]>
Date: Wed, 30 Oct 2013 21:39:26 +0000

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-masked] [[email-masked]] on behalf of Hannes Tschofenig [[email-masked]]
Sent: Wednesday, October 30, 2013 9:03 PM
To: Bjoern Hoehrmann
Cc: Vidya Narayanan; [email-masked]; [email-masked]
Subject: Re: [perpass] Explicit proxying in HTTP

Hi Vidya, Hi Bjoern,

Ciao
Hannes

> My suggestion was to include a Goal to ensure that users are in control.

_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

---

From: Vidya Narayanan <[email-masked]>
Date: Wed, 30 Oct 2013 14:47:31 -0700

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-masked]> wrote:

> From: [email-masked] [[email-masked]] on behalf of
> Hannes Tschofenig [[email-masked]]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Oct 2013 18:20:02 -0700

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-masked]> 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. 
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Oct 2013 12:07:02 +0100

Vidya,

On 10/30/13 10:47 PM, Vidya Narayanan wrote:

>
> 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
> guidelines and goals to make those detectable by the endpoints,
> including the user.

Who gets to do the authorizing?  Does the infrastructure owner get a say
how her infrastructure is used?  But before we go too far, where should
this discussion really take place?  Here or in httpbis?

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Oct 2013 11:27:18 +0000

On 10/31/2013 11:07 AM, Eliot Lear wrote:
> But before we go too far, where should

Good question.

My take: in httpbis - its on their agenda for next week I
think, and its their problem and afaik people are actively
interested in addressing it there.

It is a hard-ish problem and it could be the case that there's
stuff that'll be relevant for this list, but I think that
only makes sense after something has taken shape in httpbis
and maybe not then if they do a good enough job, which I
hope they will.

So yeah, better for this discussion to happen on the httpbis
list please.

Thanks,
S.

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 31 Oct 2013 22:43:14 -0700

All,
Thanks - I should have mentioned that the draft was submitted to httpbis (I
thought that was obvious from the naming convention).  It has been sent to
httpbis and as Stephen notes, it is on their agenda.  At this point, this
draft is only an FYI to this list - as there is an intersection in impact,
I had sent it out.

Cheers,
Vidya