Subject: Adding Security Considerations regarding interception to p1

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Sep 2013 11:30:27 +1000

In Berlin, we discussed the implications of HTTP's use of encryption upon privacy, in light of recent developments. See:
  <http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-3.pdf>

One of the proposals that got strong support in the room (i.e., very loud hum in favour, only a few humming in dissent) was adding text to Security Considerations in HTTP/1.1 to indicate the privacy implications of running without encryption.

We are very nearly ready for IETF Last Call -- possibly days away.  So, my inclination is to see if we can achieve consensus to add some text in a reasonable amount of time. 

Based on the discussion in Berlin, I've come up with proposed text for a new subsection of Security Considerations in p1. Please have a look below and indicate if you think it's a good idea to add this, disagree with adding it, or have an alternative that you think can gain consensus more easily. 

Be warned -- I don't want to rathole on this, and the easiest thing to do is not to add anything. 

---8<---

Interception and Privacy

Common use of HTTP often contains a considerable amount of Personally Identifying Information; this might include cookies [RFC6265], application data, and even patterns of access.

If used without encryption, HTTP makes this data vulnerable to passive interception. There are known instances when third parties have exploited the in-the-clear nature of "http://" URIs to obtain sensitive information, for a variety of purposes. Use of TLS [RFC2818] can mitigate such passive interception attacks.

Moreover, like other clear text protocols, HTTP/1.1 is subject to an active man-in-the-middle attack.  That is, it is possible for an intermediary
device to terminate a client TCP connection and respond as if it had the IP address of the intended HTTP server.  An attacker may insert or delete content or redirect the client to a completely different web site.  Encryption [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors. 

HTTP/1.1 does not make any particular security mechanism -- including encryption -- Mandatory to Implement, as its deployment pre-dated [RFC3631]. Nevertheless, servers ought to carefully consider the privacy implications of using HTTP without encryption (i.e., using TLS [RFC2818]), preferring its use where there is any potential for access to be considered sensitive. 

--->8---

Regards,

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Sep 2013 18:52:05 -0700

Mark - that's great and I think it is good advice to add to http/1 bis
based on operational experience.

On Tue, Sep 17, 2013 at 6:30 PM, Mark Nottingham <[email-masked]> wrote:

> In Berlin, we discussed the implications of HTTP's use of encryption upon
> privacy, in light of recent developments. See:
> One of the proposals that got strong support in the room (i.e., very loud
> hum in favour, only a few humming in dissent) was adding text to Security
> Considerations in HTTP/1.1 to indicate the privacy implications of running
> without encryption.
>
> We are very nearly ready for IETF Last Call -- possibly days away.  So, my
> inclination is to see if we can achieve consensus to add some text in a
> reasonable amount of time.
>
> Based on the discussion in Berlin, I've come up with proposed text for a
> new subsection of Security Considerations in p1. Please have a look below
> and indicate if you think it's a good idea to add this, disagree with
> adding it, or have an alternative that you think can gain consensus more
> easily.
>
> Common use of HTTP often contains a considerable amount of Personally
> Identifying Information; this might include cookies [RFC6265], application
> data, and even patterns of access.
>
> If used without encryption, HTTP makes this data vulnerable to passive
> interception. There are known instances when third parties have exploited
> the in-the-clear nature of "http://" URIs to obtain sensitive
> information, for a variety of purposes. Use of TLS [RFC2818] can mitigate
> such passive interception attacks.
>
> Moreover, like other clear text protocols, HTTP/1.1 is subject to an
> active man-in-the-middle attack.  That is, it is possible for an
> intermediary
> device to terminate a client TCP connection and respond as if it had the
> IP address of the intended HTTP server.  An attacker may insert or delete
> content or redirect the client to a completely different web site.
>  Encryption [RFC2818] may or may not mitigate this form of attack,
> depending on the client and individual behaviors.
>
> HTTP/1.1 does not make any particular security mechanism -- including
> encryption -- Mandatory to Implement, as its deployment pre-dated
> [RFC3631]. Nevertheless, servers ought to carefully consider the privacy
> implications of using HTTP without encryption (i.e., using TLS [RFC2818]),
> preferring its use where there is any potential for access to be considered
> sensitive.
>
> --->8---
>
> Regards,
>
> --

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 17 Sep 2013 19:09:40 -0700

+1

On Tue, Sep 17, 2013 at 6:52 PM, Patrick McManus <[email-masked]>wrote:

>> We are very nearly ready for IETF Last Call -- possibly days away.  So,
>> my inclination is to see if we can achieve consensus to add some text in a

---

From: "Peter Occil" <[email-masked]>
Date: Tue, 17 Sep 2013 22:30:24 -0400

I support this.  However, as written, some of the text is poorly worded:

"Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption (i.e., using TLS [RFC2818]), preferring its 
use where there is any potential for access to be considered sensitive."

Here, "its use" may be misunderstood to mean "the use of HTTP without 
encryption", which is almost certainly not the intent.  Maybe this will work 
better:

"Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption, preferring the use of encryption (such as 
TLS [RFC2818]) where there is any potential for access to be considered 
sensitive."

--Peter

-----Original Message----- 
From: Mark Nottingham
Sent: Tuesday, September 17, 2013 9:30 PM
To: IETF HTTP WG
Subject: Adding Security Considerations regarding interception to p1

Based on the discussion in Berlin, I've come up with proposed text for a new 
subsection of Security Considerations in p1. Please have a look below and 
indicate if you think it's a good idea to add this, disagree with adding it, 
or have an alternative that you think can gain consensus more easily.

Be warned -- I don't want to rathole on this, and the easiest thing to do is 
not to add anything.

---8<---

Interception and Privacy

If used without encryption, HTTP makes this data vulnerable to passive 
interception. There are known instances when third parties have exploited 
the in-the-clear nature of "http://" URIs to obtain sensitive information, 
for a variety of purposes. Use of TLS [RFC2818] can mitigate such passive 
interception attacks.

Moreover, like other clear text protocols, HTTP/1.1 is subject to an active 
man-in-the-middle attack.  That is, it is possible for an intermediary
device to terminate a client TCP connection and respond as if it had the IP 
address of the intended HTTP server.  An attacker may insert or delete 
content or redirect the client to a completely different web site. 
Encryption [RFC2818] may or may not mitigate this form of attack, depending 
on the client and individual behaviors.

HTTP/1.1 does not make any particular security mechanism -- including 
encryption -- Mandatory to Implement, as its deployment pre-dated [RFC3631]. 
Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption (i.e., using TLS [RFC2818]), preferring its 
use where there is any potential for access to be considered sensitive.

--->8---

Regards,

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Sep 2013 19:35:45 -0700

+a bunch

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Sep 2013 06:38:21 +0200

Hi Mark,

+1

And indeed there may be some more text that could be added.  I am
specifically thinking about attacks where something sent in the clear
over HTTP can be analyzed and used to gain access to something that is
protected by TLS.

Eliot

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 18 Sep 2013 00:12:10 -0700

This is confused.  TLS does not provide privacy.  HTTP rarely
contains PII (as that term is commonly defined) unless the user has
authenticated, in which case it really should be under TLS for
confidentiality (not privacy).  To get privacy, the user needs to
obscure the routing and filter the protocol stream, which can be done
by using other-protocol routing through anonymizing proxies.

Cookies are usually not PII unless they are being used to store
email or account names.  What they are, more often, is an easy
handle for data correlation over time, and eventually that correlation
might lead to a record that does contain PII, at which point the
entire data set involving that correlation becomes PII.  In any case,
this spec does not define cookies.

I really don't think we want to have that discussion in HTTP.
It is bad enough to deal with it in DNT and actual regulations.
If we want to write something useful, like the additions I made
for logfile processing, tracking, and fingerprinting, that's fine;
no more FUD.  We can reference the privacy RFC for the larger
discussion.

If we want to add a discussion about preserving confidentiality
and data integrity via TLS, that's also fine, though I personally
think it belongs in a TLS spec (not here).

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Sep 2013 08:43:47 +0000

In message <[email-masked]>, "Roy T. Fielding" w

>I really don't think we want to have that discussion in HTTP.

I agree 100%:  A disclaimer without any protocol substance to
back it up is just a waste of everybodys time.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Sep 2013 06:25:13 -0700

+1

---

From: Werner Baumann <[email-masked]>
Date: Wed, 18 Sep 2013 20:24:12 +0200

I don't like the proposed text at all. It proposes TLS as sole and
efficient means to protect privacy. That's wrong for different reason:

- TLS does not help against collecting and analyzing connection
  data, which is an important and dangerous part of the actions of
  governmental surveillance organizations.

- TLS does not help against data collection conducted by providers of
  internet services, which is an equal important threat to end user's
  privacy.

- The text only considers passive interception and man in the middle
  attacks and claims that TLS can mitigate the danger. It does not deal
  with MITM attacks on TLS-traffic which is known to happen. It ignores
  that TLS (at the moment) completely depends on the trustworthiness of
  CAs. But there is nobody who could tell for sure that these CAs are
  trustworthy. Quite the contrary. We have learned recently that even
  big companies seem to be quite defenseless when governments request
  their users data.

- It only comes up with proposals what servers should do. But it would
  be even more important to talk about what end users can do and what
  vendors of HTTP-clients should do to help end users in this (and
  what most browser vendors don't).

Discussion of security threats and measures against them is important.
But it should be done seriously. Ritually promoting the
one-size-fits-none security of TLS does not help.

Werner

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Sep 2013 20:30:52 +0200

Proposal:

If we're going to maintain privacy considerations, let's create a
separate section.  But let's also not make this a treatise on HTTP and
privacy issues.  They are all quite well documented elsewhere (albeit
not entirely in the IETF RFC series).

Eliot

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 18 Sep 2013 13:28:48 -0600

Werner Baumann wrote:
>
> We have learned recently that even big companies seem to be quite
> defenseless when governments request their users data.
> 

Erm, really?

"[N]o recipient of any Section 215 Order has challenged the legality of
such an order, despite the mechanism for doing so."

http://www.theguardian.com/law/2013/sep/17/fisa-court-bulk-phone-records-collection
http://www.wired.com/threatlevel/2013/09/telcos-metada-orders/

I believe the word is "spineless" not "defenseless".

-Eric

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Sep 2013 22:09:05 +0200

Hi Mark,

> HTTP/1.1 does not make any particular security mechanism -- including encryption -- Mandatory to Implement, as its deployment pre-dated [RFC3631]. Nevertheless, servers ought to carefully consider…

While the text seems well balanced, I still fear that is will promote
clueless deployment of TLS which will only make things worse by fooling
users into thinking they're protected.

I've worked as a consultant for a bank for 14 years, and regularly heard
the same thing : use SSL/TLS to secure a communication channel. Fortunately
a few guys *knew* it would provide nothing if the client did not check the
certs. And that situation is extremely common. Browsers, wget, curl do
verify certs. Users bypass the checks when they get an error. And other
tools (many web service clients for example) do not even check the certs.
But these deployments look safe because they're done over TLS.

I've been used to do some demos using a 2-port guruplug server setup in
bridge with haproxy running in SSL-clear-SSL mode and transparently
deciphering and reciphering traffic. You'd be amazed at the number of
devices and software which don't complain. Some SIP phones do not detect
my trivial man-in-the-middle capture device. Even some smartphone apps
connect seamlessly over WiFi this way. Thus I'd rather not promote a
blind TLS deployment when people have no clue what they're doing.

So I'd be either for not adding the text or trying to educate admins
further and not giving them any direction but only the risks so that
they look for information by themselves. Maybe removing the last
paragraph would be enough to avoid blind deployments, I don't know.

Best regards,
Willy

---

From: Nicholas Hurley <[email-masked]>
Date: Wed, 18 Sep 2013 14:37:07 -0700

+1 for this, sounds like good advice to be putting out there.

---

From: "Peter Occil" <[email-masked]>
Date: Wed, 18 Sep 2013 17:52:44 -0400

So accordingly, how would you feel with the following changes?

1. Remove the sentence:
"Use of TLS [RFC2818] can mitigate such passive interception attacks."

2. Remove the sentence:
"Encryption [RFC2818] may or may not mitigate this form of attack, depending 
on the client and individual behaviors."

Or add the following before that sentence:
"This is because, without client and server authentication, a client 
generally has no way of knowing that it is indeed communicating with the 
correct server and vice versa."

3. Change the last sentence to:
"Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption and the security implications of not using 
client and server authentication."

And perhaps mention certificates in that last sentence.

--Peter

-----Original Message----- 
From: Willy Tarreau
Sent: Wednesday, September 18, 2013 4:09 PM
To: Mark Nottingham
Cc: IETF HTTP WG
Subject: Re: Adding Security Considerations regarding interception to p1

Hi Mark,

[...]

Best regards,
Willy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 19 Sep 2013 10:41:30 +0900

What Roy, Will, and Werner have said.

I felt the same way yesterday, but they have expressed it much better.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Sep 2013 02:55:00 +0100

I saw an initial bunch of +1's to this suggestion and would
support those. This seems to me like a useful addition.

On 09/18/2013 08:12 AM, Roy T. Fielding wrote:
> This is confused.  

I don't agree. The wording can be improved I'm sure but I don't
find the suggested text at all confused or confusing.

> TLS does not provide privacy.  

Correct. But no protocol "provides" privacy. The fact that TLS
can provide confidentiality does however, make it possible
to HTTP to be more privacy friendly when compared to HTTP
without TLS.

> HTTP rarely

I don't understand the above. I don't think Mark's suggested
text claimed to give privacy, but rather to encourage folks to
use TLS as a part of being more privacy friendly. That seems to
me to be a good plan.

> this spec does not define cookies.

I don't understand the relevance of the above.

> It is bad enough to deal with it in DNT and actual regulations.

Nor that. (Really, not just being argumentative.)

> think it belongs in a TLS spec (not here).

I think encouraging more use of TLS as a part of being more
privacy friendly is worthwhile. Having said that, it may well be
a good idea to add a bit more text so that readers don't get
confused into thinking that confidentiality == privacy, so
maybe something like:

"Properly used, TLS provides good confidentiality which can be
an important part of being more privacy-friendly. However, even
the best network confidentiality service is essentially irrelevant
if the endpoints (browser, web server) are working against the
privacy expectations of users, for example by forwarding any PII
to an unwanted third party."

But even without that tweak, the suggested text is worth
adding IMO.

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Sep 2013 12:01:27 +1000

Hi Werner,

>  governmental surveillance organizations.

That's true, but I don't see how it follows that we shouldn't document TLS as a mitigation for passive interception attacks. 

>  internet services, which is an equal important threat to end user's

The scope of these documents is the protocol itself, not what is done with data once it's on someone's server.

>  big companies seem to be quite defenseless when governments request

I'm happy to add text to address this, but it seemed to me that such attacks are on TLS itself, and therefore more in-scope for it.

>  what most browser vendors don't).

Again, happy to add text. We're going to have a much more involved discussion of this for HTTP/2, however, and I suspect we'll be able to do more there. Since HTTP/1 is already widely deployed, it seemed more appropriate (as discussed in Berlin) to simply document the risk.

> one-size-fits-none security of TLS does not help.

The intent wasn't to say that TLS is the answer for all security problems, and if we need to adjust the text to take the focus away from that, it's fine. It does, however, improve things -- I hope you're not disputing that?

In my experience, many security discussions end up being about perfect and complete security. That's a very high (indeed, impossible to meet) bar, and I think it's much more reasonable to simply attempt to make things better -- a much more realistic goal.

To that point, the motivation for this text was that it seemed like a quite large omission for the revised definition of HTTP/1.1 to completely fail to document these issues. 

With that in mind, a few tweaks below:

---8<---

Interception

Common use of HTTP often contains a considerable amount of sensitive data; this might include cookies [RFC6265], application data, and even patterns of access.

When used without encryption, HTTP makes this data vulnerable to passive interception. There are known instances when third parties have exploited the in-the-clear nature of "http://" URIs to obtain sensitive information, for a variety of purposes. Use of TLS [RFC2818] can help to mitigate such passive interception attacks. Note that TLS itself has many modes of use with different security properties, and there are currently known attacks against server authentication in "https://" URIs.

Moreover, like other clear text protocols, HTTP/1.1 is subject to an active man-in-the-middle attack.  That is, it is possible for an intermediary
device to terminate a client TCP connection and respond as if it had the IP address of the intended HTTP server.  An attacker may insert or delete content or redirect the client to a completely different web site.  Using TLS [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors. 

--->8---

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 19 Sep 2013 13:07:13 +0900

Hello Mark, others,

The text below is a big improvement over the previous version, and I can 
support it.

Regards,   Martin.

On 2013/09/19 11:01, Mark Nottingham wrote:
> Hi Werner,
>
> On 19/09/2013, at 4:24 AM, Werner Baumann<[email-masked]>  wrote:
>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Sep 2013 07:39:04 +0200

On Wed, Sep 18, 2013 at 05:52:44PM -0400, Peter Occil wrote:
> "Encryption [RFC2818] may or may not mitigate this form of attack, 
> depending on the client and individual behaviors."
> 

It could probably be more exact with a mix of all that, but then does
it really provide any value to the existing document ?

I'd rather go with something much more generic in fact, like the following
idea :

"HTTP/1.1 is used for virtually every communication over the Internet today
 and as such is the target of many attacks :
  - passive interception attacks : the protocol is transported in clear text
    and may be passively intercepted by any party. This weakness has recently
    been magnified by the wide deployment of WiFi networks. Encryption may
    help reduce these risks if properly implemented.

  - active interception attacks (man in the middle) : the protocol offers no
    authentication of both ends, making it sensible to transparent proxying,
    which is used by many internet service providers to deliver cached contents
    and may be used by attackers to modify the traffic on the fly. Encryption
    with end-to-end authentication may help reduce these risks if properly
    implemented.

  - server-side attacks : log files may contain a lot of sensible information
    and are the target of some break-in attempts. Contents are also modified
    by attackers to deliver malware to many end users. These attacks are not
    related to the protocol but to its implementations and its wide deployment.

  - proxy-side attacks : corporate proxy logs are generally accessible to a
    few people who are in contact with the end users. Accessing these logs
    can become a privacy concern if browsing habits are disclosed among
    coworkers.

  - client-side attacks : malware running in browsers retrieve all contents
    in clear text before they leave the browser, and modify responses before
    they're displayed to the user. This is widely used to attack bank accounts
    and is not related to the protocol but to its implementations and its wide
    deployment.

Implementors should be aware of these threats and consider them carefully when
designing a new implementation. Encryption only solves the transport issue
between trusted parties if reciprocal authentication is enforced, but does
not address the security of the end points themselves. Logs are required to
address technical issues but should not reveal too much information. Agents
should disclose the least possible information about the users and only when
absolutely needed, as these information may still end in a network capture
or log file somewhere.
"

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Sep 2013 07:53:06 +0200

On Thu, Sep 19, 2013 at 02:55:00AM +0100, Stephen Farrell wrote:
> "Properly used, TLS provides good confidentiality

The problem is precisely here. The mechanism is too complex for the
casual web admin to deploy it correctly and to understand the
implications of his choices. Not to mention the client side which
is generally worse as soon as it's not a browser. TLS is only safe
iff properly used and very few people know how to use it properly.
Thus they deploy and feel safe, so they have nothing else to care
about.

The only really safe implementations I have seen were in clear text.
Why ? Simply because their authors knew that a TLS deployment would
eventually be degraded by clueless admins so they considered that
they needed to have something robust even when TLS was broken. As
a result they did all the job in the application (encrypting/signing
sensible data, timestamping/signing HTTP headers) and the transport
was as safe as a good TLS deployment without the risk that the
transport would be degraded further.

That's why I don't like promoting it as the easiest path to confidentiality.
It's only one element but we tend too often to spread the word that it's
sufficient, which is totally wrong and counter-productive.

Willy

---

From: Mike Belshe <[email-masked]>
Date: Thu, 19 Sep 2013 00:00:28 -0700

Mark -

I was about to write that I didn't like your proposal :-(

But after reading Willy's argument, maybe I see a route where it can be
useful.  Specifically, Willy's retort is the common one - discussing "dumb
administrators" and that TLS is not a panacea.  This argument doesn't
appeal to me because any of us can craft a reasonable story about the
clueless guy to support our own point of view.  And the clueless guys don't
read protocol specs anyway :-)

But we don't need to talk about the clueless guy, because even smart
administrators that do read these specs don't always know when to encrypt.
 This could be demonstrated with an example.  Appending to your own text:

Common use of HTTP often contains a considerable amount of sensitive data;
this might include cookies [RFC6265], application data, and even patterns
of access.

When used without encryption, HTTP makes this data vulnerable to passive
interception. There are known instances when third parties have exploited
the in-the-clear nature of "http://" URIs to obtain sensitive information,
for a variety of purposes. Use of TLS [RFC2818] can help to mitigate such
passive interception attacks. Note that TLS itself has many modes of use
with different security properties, and there are currently known attacks
against server authentication in "https://" URIs.

*Content providers should be aware that while content may be public
information, and seemingly not "sensitive", a consumer being observed
accessing that information may still be sensitive.  For example:  suppose
an encyclopedia content provider has a public page on sexually transmitted
diseases.  There is nothing confidential or private in that page.  A
medical student may access that page as research, and not care whether it
is publicly known that they viewed that page.  However, a patient may be
accessing that page because they are researching a sensitive issue.  This
user, unlike either the content provider or the medical researcher,
benefits from additional privacy when the content is deployed via HTTP/TLS
rather than with HTTP alone.*

I dunno - I'm still not in love with this - words without teeth are very
close to pontificating, and I'd rather hold out for a protocol that
actually walks the talk...  Can we do that instead? :-)

Mike

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 19 Sep 2013 17:17:45 +1000

> …and there are currently known attacks against server authentication in "https://" URIs…

What is this phrase alluding to? I’m not sure it helps here.

--
James Manger

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Sep 2013 09:47:11 +0200

Hi Mike,

> read protocol specs anyway :-)

I don't agree with you here. The people who are able to correctly deploy
TLS don't need to read our warnings about the risks of transporting HTTP
in clear text. However the newcomers who have no clue about these risks
have even less clues about how to correctly deploy TLS. And the situation
is already bad because they constantly hear "simply switch to https if
you transport anything sensible such as a password". Which is wrong and
regularly leads to information leaks because they don't understand that
it's more complex than that. BTW, we all know educated people around us
who renew their certs without changing their private keys because this
is not needed, right ? Except that it completely voids the main goal of
limiting the cert's lifetime. This is one of the mistakes that many
people fall through and that render their implementations insecure.

> administrators that do read these specs don't always know when to encrypt.

Exactly. If you think you need to add TLS to your HTTP stack, then you
should consult and expert and not believe you can do it correctly by
yourself otherwise it will probably be useless. That's the message I
would like to pass if we mention TLS.

Regards,
Willy

---

From: "Eric J. Bowman" <[email-masked]>
Date: Thu, 19 Sep 2013 02:00:54 -0600

Willy Tarreau wrote:
> 
> I'd rather go with something much more generic in fact, like the
> following idea :
> 

+ 3/4

A bit rough around the edges, but on the right track -- I like this as a
starting point better than the other proposed wording.

-Eric

---

From: Werner Baumann <[email-masked]>
Date: Thu, 19 Sep 2013 20:34:08 +0200

+1
Werner

Am Thu, 19 Sep 2013 07:39:04 +0200
schrieb Willy Tarreau <[email-masked]>:

> "HTTP/1.1 is used for virtually every communication over the Internet
> today and as such is the target of many attacks :
>   - passive interception attacks : the protocol is transported in
> clear text and may be passively intercepted by any party. This
> weakness has recently been magnified by the wide deployment of WiFi
> networks. Encryption may help reduce these risks if properly
> implemented.
> 
>   - active interception attacks (man in the middle) : the protocol
> offers no authentication of both ends, making it sensible to
> transparent proxying, which is used by many internet service
> providers to deliver cached contents and may be used by attackers to
> modify the traffic on the fly. Encryption with end-to-end
> authentication may help reduce these risks if properly implemented.
> 
>   - server-side attacks : log files may contain a lot of sensible
> information and are the target of some break-in attempts. Contents
> are also modified by attackers to deliver malware to many end users.
> These attacks are not related to the protocol but to its
> implementations and its wide deployment.
> 
>   - proxy-side attacks : corporate proxy logs are generally
> accessible to a few people who are in contact with the end users.
> Accessing these logs can become a privacy concern if browsing habits
> are disclosed among coworkers.
> 
>   - client-side attacks : malware running in browsers retrieve all
> contents in clear text before they leave the browser, and modify
> responses before they're displayed to the user. This is widely used
> to attack bank accounts and is not related to the protocol but to its
> implementations and its wide deployment.
> 
> Implementors should be aware of these threats and consider them
> carefully when designing a new implementation. Encryption only solves
> the transport issue between trusted parties if reciprocal
> authentication is enforced, but does not address the security of the
> end points themselves. Logs are required to address technical issues
> but should not reveal too much information. Agents should disclose
> the least possible information about the users and only when
> absolutely needed, as these information may still end in a network
> capture or log file somewhere. "
> 
> Willy
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Sep 2013 10:50:42 +1000

On 19/09/2013, at 5:00 PM, Mike Belshe <[email-masked]> wrote:

> I dunno - I'm still not in love with this - words without teeth are very close to pontificating, and I'd rather hold out for a protocol that actually walks the talk...  Can we do that instead? :-)

I hear you.

I'm suspecting we're not going to be able to achieve consensus on this, especially since it isn't a technical argument.

Unless the discussion converges on a broadly acceptable proposal in the next day or so, we'll go to LC without this text, and I'll record in the shepherd's writeup that this was a contentious issue. Note that one of the possible outcomes is that the IESG will send it back to us and instruct us to say something about interception; they could also decide we shouldn't. Having them make the decision saves us a lot of back-and-forth.

One thing I'll reiterate; we're not expected to document the complete story regarding privacy, interception, etc; the only purpose of putting this text in was so that we mention -- not completely define -- the topic. AIUI there are other specs in the works for that.

Regards,

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Sep 2013 07:10:17 +0200

Hi Mark,

On Fri, Sep 20, 2013 at 10:50:42AM +1000, Mark Nottingham wrote:
> I'm suspecting we're not going to be able to achieve consensus on this,
> especially since it isn't a technical argument.
> 
> Unless the discussion converges on a broadly acceptable proposal in the next
> day or so, we'll go to LC without this text, and I'll record in the
> shepherd's writeup that this was a contentious issue. Note that one of the
> possible outcomes is that the IESG will send it back to us and instruct us to
> say something about interception; they could also decide we shouldn't. Having
> them make the decision saves us a lot of back-and-forth.
> 
> One thing I'll reiterate; we're not expected to document the complete story
> regarding privacy, interception, etc; the only purpose of putting this text
> in was so that we mention -- not completely define -- the topic. AIUI there
> are other specs in the works for that.

Then what do you think about just describing the current state without
giving any guidance about how to protect, so that the reader informs
himself on the subject if he feels concerned ?

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Sep 2013 15:14:27 +1000

> himself on the subject if he feels concerned ?

Personally - I think that'd be a big improvement over saying nothing. However, AIUI the security folks like to see a listing of both threats *and* mitigations for them. Stephen?

The second proposal I made (copied below) tried to make it clear that while TLS might help, it's not a panacea. Are you still against it? Would adding further qualifications about TLS help?

Regards,

---8<---

Interception

--->8---

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Sep 2013 07:51:42 +0200

On Fri, Sep 20, 2013 at 03:14:27PM +1000, Mark Nottingham wrote:
> Personally - I think that'd be a big improvement over saying nothing.
> However, AIUI the security folks like to see a listing of both threats *and*
> mitigations for them. Stephen?
> 
> The second proposal I made (copied below) tried to make it clear that while
> TLS might help, it's not a panacea. Are you still against it? Would adding
> further qualifications about TLS help?

I thought I had replied but can't find my reply, maybe I dreamed.

I find it better, but I'm still worried about promoting TLS to fix this
with half a solution because we present TLS as a drop-in fix which is not
true. I think there is nothing wrong in saying that TLS completely addresses
the issues only when reciprocal authentication is used (ie where the client
can be trusted as well), and most of the issues (especially related to web
browsing) when the server's authentication is enforced on the client. Also
we must not forget that this will probably be the last spec of HTTP/1.1 and
that it will live forever. Who knows if TLS will still exist in 10 years ?
We killed SSLv2 pretty quickly for example. That's why I'd rather talk about
the principles than explicitly suggesting protocols that we might regret
later (though they should be cited as examples).

Passive interception on the web is just a detail IMHO. TCP connections are
very short and if you miss one request because you could not intercept the
beginning, you'll have the remaining parts a few hundreds of milliseconds
later, and you can even reset the connection to make the client retransmit
in many cases. And if you can sniff, you can intercept and put yourself as
a man in the middle. It is already trivial to do on public WiFi networks.
In switched environments, you even *have* to insert yourself as a man in
the middle in order to sniff the traffic. The only difference between passive
and active interception is with captured traces that you have to analyse
later. So it should be better IMHO to focus on the ability for anyone to
intercept the whole traffic.

A few participants seem to be interested in the approach I proposed,
consisting in describing a number of known threats, and the ones that
can be addressed. The wording is not good, but the general idea was
there. I think that if we could articulate your proposal the same way
it would be more balanced. Do you have an opinion on this ?

Regards,
Willy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Sep 2013 07:52:53 +0200

> Personally - I think that'd be a big improvement over saying nothing. However, AIUI the security folks like to see a listing of both threats *and* mitigations for them. Stephen?

I'm not Stephen, but that is what a security considerations section is
for.  The problem is twofold.  We mixed it with privacy considerations,
and they are somewhat different, albeit very related, and one could
write several volumes on both for HTTP.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 11:50:27 +0100

Hi Willy, Mark,

>> mitigations for them. Stephen?

Given that HTTP/TLS is one of the widely deployed countermeasures
on the Internet and is startlingly obvious here, I think saying
nothing about that countermeasure would be pretty dim.

I'm not sure if there's good text somewhere on how to properly
use TLS for HTTP (and I'm not saying I'd insist on that here), but
it'd be a good thing if there were. This line

  "Held / eliminated - Working Group Last Call for HTTP
   Security Properties"

from this wg's charter is sad though.

> true. 

That seems purely pejorative to me. In practice, TLS is the too
that's available here. Ignoring that because its imperfect would
be dumb.

> I think there is nothing wrong in saying that TLS completely addresses
> browsing) when the server's authentication is enforced on the client. 

I have no idea what you mean. Are you saying that client-auth is
required in order to do better with privacy? That'd seem like a
load of nonsense, so I guess you're not saying that.

> Also

Now that's definite nonsense. The probability that HTTP (of any
version) will be protected only using technology that's not
genetically related to TLS in 2023 can only be reasonably
estimated at zero.

> Passive interception on the web is just a detail IMHO. 

Recent events would seem to indicate otherwise unless you consider
all of Snowdonia to be a "detail".

I would love to see this WG do a great job of helping folks to
deploy HTTP1.1 over TLS better. It should though at least
acknowledge the issues and the major countermeasure that does
get deployed and encourage that. And I think text along the
lines Mark initially suggested, or some of the reasonable
alternative suggestions, seems like the minimum that needs to
be done.

S.

> TCP connections are

---

From: Patrick McManus <[email-masked]>
Date: Fri, 20 Sep 2013 05:06:39 -0700

> alternative suggestions, seems like the minimum that needs to

right on.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Sep 2013 18:30:10 +0200

Hi Stephen,

> that's available here. Ignoring that because its imperfect would

That's not my point, my point is that it's fairly possible to use TLS as
badly as clear text, providing no security at all with the difference that
you feel secure. And to me, feeling secure is much worse than not feeling
secure.

> required in order to do better with privacy?

Not privacy, but security in general. And in some cases it can even be about
privacy. When my tax office requires my cert to log in, I'm more confident
that I'm the only one to be able to consult my account than if it only
requires my previous tax amount.

> That'd seem like a load of nonsense, so I guess you're not saying that.

For the general web I'm not saying that.

> genetically related to TLS in 2023 can only be reasonably

Maybe in 2013 we'll be saying everywhere "please stop using TLS, it's totally
dead and cracked, disable it by default from browsers" as we used to say about
SSLv2 for a long time. Except that if a standard recommends a precise
implementation, it creates confusion and discredits all the standard. I'd
rather say "use encryption and authentication which at this time is provided
by TLS when properly deployed" than "use TLS".

> all of Snowdonia to be a "detail".

I don't know, I've never heard about "Snowdonia", all I can find is
related to a city. However, my point remains that many times, passive
interception already requires active interception (presenting yourself
as the gateway), which is true in switched networks. Right now it's
enough to just route the traffic, but it's not harder to proxy it
when you can route it. And students with nothing to do on their holidays
will quickly come with an easy to use tool. Look how Firesheep appeared!
Who would have imagined that it was possible to sniff from a browser!

> deploy HTTP1.1 over TLS better.

That's my goal as well, and I think that telling them that using TLS
*correctly* is a solution is fine, but making them believe that "just
switching to TLS" is the solution is worse than the current solution.

> It should though at least

Yes very likely, which is why I've been proposing some ideas which
I know are not properly worded, but try to help spot the correct line
between the two.

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Fri, 20 Sep 2013 10:49:41 -0700

> you feel secure. And to me, feeling secure is much worse than not feeling

-----

*NEWSWIRE:  Sept 20, 2013   HTTP/2.0 Team Officially Changes Charter.   New
goals include*
*making sure nobody feels secure.*

"We've known for some time that HTTP is an insecure protocol.  We thought
about improving security,
and we even have the technology to do it.  But we couldn't agree how to do
it.  So, we
decided that as long as nobody feels secure, we simply don't need to."
 said HTTP chair Mark
Nottingham.

HTTP, of course, is one of the core protocols of today's internet and has
never
been an encrypted protocol.  Recent news from the NSA shows that the US
government
joins the ranks of most other information-age governments with extensive
use of internet sniffing to track users around the globe.

"I thought the IETF was one organization which was helping protect the
internet," said an
Internet user.  "I guess I was wrong."

Other HTTP members, such as HTTP team member Roberto Peon, see this as
opportunity.
"We've been frustrated with our adversarial relationship with the NSA for
some time.  With
this new charter, we don't have to.  Our interests are now completely
aligned with the NSA.
We should all be afraid.  Isn't it great?"

So, while internet users everywhere will soon fear using their computers,
the HTTP team
is back on track to do absolutely nothing to secure its protocols this
year.  It's really not
a change, except now they're doing their job.

-------

Mike