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

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Fri, 12 March 2010 01:42 UTC

Return-Path: <yngve@opera.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 7519C3A6991 for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 17:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
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 6c4n4CL1KDxo for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 17:42:23 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id C47103A697E for <http-state@ietf.org>; Thu, 11 Mar 2010 17:42:22 -0800 (PST)
Received: from acorna (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2C1gNMN004441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Mar 2010 01:42:24 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Gonzalo Salgueiro" <gsalguei@cisco.com>, http-state@ietf.org
References: <E022D1C0-F0DF-4BF3-B309-317B38314788@cisco.com>
Date: Fri, 12 Mar 2010 02:42:20 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Message-ID: <op.u9floursqrq7tp@acorna>
In-Reply-To: <E022D1C0-F0DF-4BF3-B309-317B38314788@cisco.com>
User-Agent: Opera Mail/10.10 (Win32)
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 01:42:24 -0000

Hi,

Some comments on this draft below

On Fri, 19 Feb 2010 00:45:03 +0100, Gonzalo Salgueiro <gsalguei@cisco.com>  
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: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************