Subject: Re: [http-state] draft-salgueiro-secure-state-management

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 12 Mar 2010 02:42:20 +0100

Hi,

Some comments on this draft below

On Fri, 19 Feb 2010 00:45:03 +0100, Gonzalo Salgueiro <[email-masked]>  
wrote:

> Folks -
>
> I have posted the following draft:
>
> http://tools.ietf.org/html/draft-salgueiro-secure-state-management
>
> This draft provides a simple method for providing a reasonable level of  
> security when exchanging state management information through HTTP in  
> situations where TLS is not employed.
>
> We would appreciate receiving any comments you have and input on whether  
> you think this might be a complementary addition to the work the WG is  
> already undertaking.

* 1.1 "In practice, the use of HTTPS requires a unique IP address per URL"

This is no longer the case, as the draft notes, due to SNI, but any secure  
server can host multiple servers by using either wildcard certificates or  
a certificate that lists multiple hostnames. The process for obtaining  
such certificates may be a bit more complex and probably somewhat more  
expensive, but probably less so than using multiple physical machines. But  
is the multiple hostnames needed in most cases, anyway?

* 1.2 "Using HTTPS consumes more processing time and resources"

The costly step is actually the initial handshake, due to the PKI step,  
not the session resume or the steady traffic, and hardware acceleration  
helps on all of these if the traffic is heavy enough. If this becomes  
costly it is IMO either due to bad configuration of TLS session  
management, low connection persistence, or by using too many different  
hostnames to provide content.

* 1.3 Ordinary Domain validated certificates are very inexpensive  (Some  
probably think too inexpensive, but that is another discussion), and  
obtaining one is not that time consuming. Obtaining certificates that  
provides higher assurance do get more expensive and time consuming, but  
that is something you will do if you need to project that kind of  
assurance to your users. Of course, this may vary depending on which TLD  
you are operating in.

* 1.4 "TCO" Learning how to operate a secure server may be a little  
time-consuming, but I doubt the process of configuring one increases the  
time spent administrating the server significantly.

* 1.5 "Expired certs" One way to fix expired certs: Don't let them expire.  
Most CAs are very helpful about reminding you. A little provocatively one  
can say that updating the certificate on time may be an indicator of how  
serious you are about your business. Just this week a major Norwegian  
government portal _forgot_ to update the certificate that was ready to be  
installed.

* 1.6 "Not everything needs to be encrypted": IMNSHO if anything at all  
needs to be encrypted, everything should be encrypted. It is too easy to  
let something sensitive slip into the unencrypted part of the system. And  
if you are swapping back and forth suddenly you are mixing secure and  
unsecure content.

* 1.7 "routers and compression": Plain text also opens the user up to Deep  
packet inspection and privacy invasion. Adding compression in the TLS  
client is probably almost as efficient. Is suspect, however, that there  
are other resources that, like audio and video, even while unencrypted, is  
a much larger percentage of the traffic than what is affected by the kind  
of requests we are talking about here.

Many of the reasons for not using TLS stated in Section 1 may have been  
true years ago, but AFAIK there is infrastructure in place now to  
eliminate or drastically reduce the mentioned issues.

In any case, my opinion is that if something is sensitive enough to be  
encrypted, then what the result is used to provide access to is probably  
also worth encrypting.

Section 4:

* It is not a good idea to have default g and p values

Section 8:

* I am not sure it is a good idea to have the nonce as a direct part of  
the encrypted part, it should be part of a digest instead. This system is  
also missing any kind of real integrity check, since I doubt the nonce is  
able to provide good enough protection by itself. Also, having the nonce  
as predictable plaintext could give an attacker enough data on which to  
base a brute force attack on the encryption key, although I doubt it is  
feasible today.

* The nonces could cause issues when multiple parallel requests are used,  
possibly out of order, or the client is forced to send one request  
multiple times.

Section 9:

* "Race to the server" An attacker that is able to read the DH-Cookie must  
also be presumed able to block/suspend the client's HTTP connection as  
long as he want, and at least long enough to carry through an attack.  
(After all, that is what made the TLS renego attack work)

I could probably go into further detail about the system, but my  
conclusion is that it will not provide any extra security for the  
information, except against two specific types of adversaries: A passive  
eavesdropper and an active attacker that started working after the  
handshake completed, and I don't think we can rely on only encountering  
those.

Against an active attacker (MITM) this method does not (as the draft  
admit) provide any security since the attacker is able to establish a  
session using his own DH key instead, because there is no end-to-end  
verification of the key agreement.

Essentially, IMO this system does not realistically provide any better  
security than the current cookie system.

To be able to provide realistic security at least two things are needed: A  
server signature of the DH keys, and an end-to-end verification of the  
handshake so that both the client and the server can be assured nobody is  
eavesdropping on the encrypted parts of the exchange or manipulating it.  
All of this is already provided by TLS, and if further protection is  
needed, encryption keys can be agreed upon by using the TLS Keying  
Material Exporter mechanism  
<http://www.ietf.org/id/draft-ietf-tls-extractor-07.txt >

Even given a better key exchange I am not sure this is needed. Servers can  
protect the information on their own if needed. Also, TLS will provide  
quite a lot of protection (including authentication), and Digest  
authentication (which might need improvements on its own) can identify  
users well enough (and securely enough for most purposes) to associate  
them with a serverside state that does not have to be maintained by the  
client, except maybe as a identifying token.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Mar 2010 02:57:26 -0500

Yngve,

> Some comments on this draft below

Thanks for providing such a thorough review of the draft.  I'll try to
respond to your comments below.

> is the multiple hostnames needed in most cases, anyway?

Web hosting providers host dozens of domains per server owned by different
individuals or businesses.  While not all domains would require a TLS
certificate, if there is more than two that do, it presents an issue.  SNI
will address this, but it will take some time for this support to be
universal.  Granted, it might not be faster than an alternative cookie
exchange mechanism, but if a browser does not support a secure cookie, then
the server can fallback to insecure cookies.  There is no fallback in the
face of lack of support for SNI.  So, this is still a relevant point, I
think.

> hostnames to provide content.

It is true that the initial handshake is most costly, but that's a real
issue.  Most interactions with a server are small GET requests.  On a
servers with heavy load (e.g., facebook.com), use of TLS introduces
significantly higher load.  In some of our own tests, we've seen significant
differences in capacity on web servers when using TLS.  It's significant
enough to consider exploring alternatives.
 
> assurance to your users. Of course, this may vary depending on which

For organizations like universities, the cost can be rather expensive.  One
department (or group therein) cannot share the same certificates
necessarily, so numerous certificates may be required.  For sites like
blogs, etc., one might consider certificates to be rather excessive, with
many certificate authorities selling certs at 3x or 10x the price of a
domain name.

Certificates must also be changed periodically (usually 1 year), which can
be rather burdensome.

Security is important, but there is always a balance one must strike between
security and cost (in terms of money, time, and effort).

In any case, we're not proposing a replacement of TLS, by any means.  In
fact, one may still wish to use TLS in conjunction with what we're proposing
in this draft.
 
> time spent administrating the server significantly.

All things like this are relative.  If you employ a person full-time to
manage servers like this, it's not a problem.  But, if you own a few blogs
and every year have to spend 30 minutes every now and then to acquire a new
certificate... sure, it's not a lot of time, but it's time nonetheless that
one might prefer to spend elsewhere.
 
> government portal _forgot_ to update the certificate that was ready to

This is a related idea to the previous.  We did not intend to paint such a
ugly picture of digital certificates.  The fact is, though, there are a
number of reasons why one may not wish to employ TLS.
 
> if you are swapping back and forth suddenly you are mixing secure and

One might want to allow users to log in using a secure connection, but then
everything else uses regular HTTP.  If a web site serves only public
content, then the only thing that truly needs protecting whatever mechanism
is used to manage session state (e.g., a cookie).  A web server might use
TLS or digest authentication to authenticate the user, but then employ a
cookie.  Many sites do that, in fact, but it leaves the session open to
hijacking.
 
> of requests we are talking about here.

Your points are all valid, though this does not negate the fact that using
HTTP can result in reduction in processing on the server and will enable
higher compression capabilities on a lot of content over some network links.
If one is concerned about DPI, etc., then TLS should be used.
 
> eliminate or drastically reduce the mentioned issues.

TLS is definitely an issue in some environments.  Even on my own personal
server, I cannot employ SNI -- I need to upgrade the OS.  The burden on the
server is very real and something that has presented my team with certain
challenges when trying to scale.  But, again, we're not proposing to do away
with TLS.  I certainly would expect my bank to use TLS, but I don't need TLS
when posting content on Slashdot, for example.
 
> encrypted, then what the result is used to provide access to is

It's not the content (i.e., the message body) we're worried with, but the
risk that someone might grab a token through passive monitoring and then
gain access to resources.  Such an individual might then post content,
delete content, etc.

This draft does not deal with securing content, but securing access to
content.
 
> * It is not a good idea to have default g and p values

Why?  I've seen this done a number of times with various protocols, and
they're certainly not secret values.
 
> base a brute force attack on the encryption key, although I doubt it is

The purpose for concatenating the nonce is so that we can produce blocks of
encrypted data that unique and not subject to a replay attack.

We may want to have a MAC to help ensure that the data has not been altered
in transit, but this was not really a concern.  The reason is that nothing
could alter the data in transit unless it is also a MiM, in which case it
would have access to the DH keys, anyway :)  Nonetheless, I'm certainly not
opposed to introducing a MAC if it is preferred.

> possibly out of order, or the client is forced to send one request

This is the reason for having an "association".  Each parallel request would
establish its own, separate association.  There would never be two requests
in parallel using the same assoc value.
 
> (After all, that is what made the TLS renego attack work)

Yes, this is certainly a risk for which I don't have a remedy.
 
> handshake completed, and I don't think we can rely on only encountering

You're correct, but that was our objective.  TLS is excellent when we wish
to secure everything end-to-end.  Without TLS, there is absolutely no
security at all.  In our opinion, there is a need to prevent passive attacks
from taking place so trivially.
 
> verification of the key agreement.

A possible solution to this is to use TLS to perform the DH operation *or*
to simply send the key over the wire from the server.  So, if a web site
(e.g., Facebook) wanted to secure the login process and ensure there was no
possibility of a MiM could intercept the key, it could design the system in
that way.  The balance of the traffic, though, could be exchanged in the
clear and the session served to the right user based on the encrypted cookie
passed on the wire.
 
> security than the current cookie system.

I disagree on this point, because today we have TLS or nothing.  Given the
inordinate number of web sites that do not use TLS, yet maintain session
state, I think we need a solution in the middle.
 
> <http://www.ietf.org/id/draft-ietf-tls-extractor-07.txt >

As mentioned above, we would use TLS to aid in exchanging the key used to
encrypt the cookie.  In fact, rather than calling it "DH-Cookie", perhaps we
call it "Secure-Cookie".  DH might just be one means of negotiating the key.
One can choose the level of security one feels appropriate for the
environment.
 
> client, except maybe as a identifying token.

As I mentioned above, the goal of this draft is not to displace TLS, but to
provide a better solution to state management than what we see on the vast
majority of web sites on the Internet today -- which is no security
whatsoever.  Using a mechanism like what we propose in the draft would also
solve a very real scaling issue we have with the use of TLS in a project I'm
working on, which is actually one thing that prompted us to write this
draft.

We have a desire to try to provide a reasonable level of security against
the illegitimate access to resources that do not need encryption.  We're
certainly open to discussion on how to improve it, perhaps looking at other
mechanisms for exchanging keying information.  That said, I would hope we
could keep it simple and design something that could be easily adopted.
Personally, I really like cookies, in spite of the calls for their demise
:-) Even so, it does concern me that sessions can be so easily hijacked
today.

Paul

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 12 Mar 2010 12:07:32 +0100

> they're certainly not secret values.

Mostly I am concerned about being able to use prior knowledge about what  
the client uses to weaken security

> in parallel using the same assoc value.

The parallel requests I am primarily referring to are, for example, inline  
resource requests (for images, scripts, etc.) sent across multiple  
parallel connections, and which can be sent pipelined. Clients seldom keep  
just one connection open to a server that have several resources the  
client needs.

BTW, about separate tabs having separate associations: Opera, at least,  
does not normally separate URLs in tabs from each other, except in special  
situations like the Private Mode. Tabs normally share the cookies,  
including document.cookie cookies, and it would IMO not be practical to  
add this as a special case.

> from taking place so trivially.

That may be, but only targeting passive attackers is IMO not enough of a  
reason for this, particularly when TLS can be used to avoid both that type  
of attacker and the active attacker.

> clear and the session served to the right user based on the encrypted  

Possible. See my comment about using TLS extractor for key-agreement,  
which would eliminate the separate DH operation, and implicitly protect  
the operation against passive and active attackers, as long as they are  
not able to attack the SSL connection.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Mar 2010 11:40:48 -0500

Yngve,

> the client uses to weaken security

I would like to hear other opinions on this, but it seems like this one is
not really an issue.  The important thing is to ensure we have proper
values, but the clients will use random numbers that will be extremely
challenging even with knowledge of these two values, I think.

> > This is the reason for having an "association".  Each parallel
> request
> > would

I understand.  Requests over a separate connection would require a separate
association.
 
> add this as a special case.

This is really important feedback.  Clearly, we don't want to create a
burden for either the client or server.  I had assumed that the cookie value
(unencrypted) would be maintained globally as it is today.  Each tab,
though, or each thread that issues separate requests would establish its own
association.

In the simplest case, an association could be established with each tab and
the association data could be discarded when closed.  Would that approach
help?

I would prefer to cache the association data for a longer period of time (24
hours?) and have a mechanism to prevent two requests from using the same
value at the same time, but I am more interested in making this simple.

> > You're correct, but that was [not] our objective.  TLS is excellent when
we
> > wish

Given that TLS is not universally employed, even by companies that have the
resources to do it (like Facebook), does that not provide you with
sufficient evidence that we should take steps to protect end-users with
something better than nothing?  I think we should, but I guess you disagree.

> > (e.g., Facebook) wanted to secure the login process and ensure there
> was
> > no
> > possibility of a MiM could intercept the key, it could design the
> system
> > in

We will.  It seems we need to consider both a means of exchanging a key via
DH and TLS.

Paul