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

"Paul E. Jones" <paulej@packetizer.com> Fri, 12 March 2010 07:57 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E12A3A6B0A for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 23:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1bZHinp5gxf for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 23:57:37 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 96C233A6A48 for <http-state@ietf.org>; Thu, 11 Mar 2010 23:57:35 -0800 (PST)
Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o2C7vYI1009058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Mar 2010 02:57:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1268380659; bh=gU7kcqSG3549PG2xuz1TE+MAu4krQByDp4VmgAai93g=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9bMDmnND18C5+LKYkVHBU0bSa2a8tD8Dud9lRFg4WQcJiHEcZtM3J86ci8fDEbic AzhBzN08ofM364g/UFyh9SxJ8wYWlLaayGJ/VI1Uy8kk7cCfziZrTrTF94Yeq+Oczc vOkuaJqXU/ulqxOZ499sBtHfJmpHL92Lj+lZx3W0=
Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o2C7vXms025306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Mar 2010 02:57:33 -0500
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" <yngve@opera.com>, "'Gonzalo Salgueiro'" <gsalguei@cisco.com>, <http-state@ietf.org>
References: <E022D1C0-F0DF-4BF3-B309-317B38314788@cisco.com> <op.u9floursqrq7tp@acorna>
In-Reply-To: <op.u9floursqrq7tp@acorna>
Date: Fri, 12 Mar 2010 02:57:26 -0500
Message-ID: <008401cac1b9$a7f767c0$f7e63740$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrBhU2W/v/00rCoSMucb/q1U+k8BAAI9Rrg
Content-Language: en-us
Subject: Re: [http-state] draft-salgueiro-secure-state-management
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2010 07:57:39 -0000

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.

> * 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?

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.

> * 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.

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.
 
> * 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.

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.
 
> * 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.

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.
 
> * 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.

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.
 
> * 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.

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.
 
> * 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.

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

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

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.
 
> Section 4:
> 
> * 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.
 
> 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 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.

> * 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.

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.
 
> 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)

Yes, this is certainly a risk for which I don't have a remedy.
 
> 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.

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

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.
 
> Essentially, IMO this system does not realistically provide any better
> 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.
 
> 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 >

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

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