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

"Paul E. Jones" <paulej@packetizer.com> Fri, 02 July 2010 04:09 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 D1A4F3A67B3 for <http-state@core3.amsl.com>; Thu, 1 Jul 2010 21:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.728
X-Spam-Level:
X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.871, 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 eCFCMxAhg1xa for <http-state@core3.amsl.com>; Thu, 1 Jul 2010 21:09:09 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 979F23A6767 for <http-state@ietf.org>; Thu, 1 Jul 2010 21:09:09 -0700 (PDT)
Received: from sydney (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 o6248SRu018049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 00:08:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1278043715; bh=Kb5Im2zDZUcZE1e/TGCxLi1eozq7WWP2cfIq2/YqjF0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JG3OsfuiqKDa4BAIlxSchbE0hWuhr+nblXG9pt6775C5d1VGSbOuOxGlXq/MSLn/U LVnxQ2hgW2Ma5OTAiPieVAlIL1fmiRMtm/NJD7dApC/6sRLvoePtLas+ifTH3vn8/6 lqWms0nzKzW+cU6A8JYfHuJ269eB3e46YuWr7LF8=
From: "Paul E. Jones" <paulej@packetizer.com>
To: <yngve@opera.com>, "'Gonzalo Salgueiro'" <gsalguei@cisco.com>, <http-state@ietf.org>
References: <E022D1C0-F0DF-4BF3-B309-317B38314788@cisco.com> <op.u9floursqrq7tp@acorna> <008401cac1b9$a7f767c0$f7e63740$@com> <op.u9gbuuzqqrq7tp@acorna> <005001cae689$ce603500$6b209f00$@com> <op.ve6bw9z3vqd7e2@killashandra.oslo.osa>
In-Reply-To: <op.ve6bw9z3vqd7e2@killashandra.oslo.osa>
Date: Fri, 2 Jul 2010 00:08:19 -0400
Message-ID: <056f01cb199c$3831c710$a8955530$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH9U7I5KrIwDik6w4twG+LLgT00QwGB8mTPAmmzQiQBZRwhxAL9FFU4Ala8+9aR42jpcA==
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, 02 Jul 2010 04:09:10 -0000

Yngve,

I'll confess that we must have overlooked your proposal when putting
together this latest version.  The previous version of the document just
specified the use of DH over HTTP.  This most recent document specifies the
transmission of a random number in the HTTPS response, which the server
would generate to align with the encryption algorithm used to encrypt the
cookies.

The reasons you cite for using this RFC are that it:
* Removes the overhead caused by establishing an independent key agreement
protocol
* Makes the key agreement independent of any specific algorithm

In our draft, we actually do not specify the use of a key agreement
mechanism over TLS at all, but merely transmit the key from the server to
the client over the encrypted TLS connection.  Do you believe this approach
has negative security implications that this RFC will address?  More
generally, do you feel that we need to introduce a key agreement mechanism
where both the client and server play some role in defining what the
symmetric key shall be for encrypting cookies?

As I said, we assumed it was acceptable for the server to specify that key
since the connection was already secured with TLS, but we're certainly open
to further dialog to improve the security.

Paul

> -----Original Message-----
> From: Yngve Nysaeter Pettersen [mailto:yngve@opera.com]
> Sent: Thursday, July 01, 2010 12:55 PM
> To: 'Gonzalo Salgueiro'; http-state@ietf.org; Paul E. Jones
> Subject: Re: [http-state] draft-salgueiro-secure-state-management
> 
> Hi,
> 
> As I indicated earlier, I would strongly suggest that you replace the
> current key agreement with the method described in RFC 5705 ("Keying
> Material Exporters for Transport Layer Security") which uses an already
> established TLS connection and master secret to agree on the encryption
> key, removing the overhead caused by establishing an independent key
> agreement protocol, and also makes the key agreement independent of any
> specific algorithm, instead relying on the TLS protocol's security.
> 
> http://datatracker.ietf.org/doc/rfc5705/
> 
> 
> On Wed, 28 Apr 2010 06:18:07 +0200, Paul E. Jones <paulej@packetizer.com>
> wrote:
> 
> > Yngve, et al.,
> >
> > We took everybody's comments into consideration and revised the draft
> > to add a means of exchanging the encryption key used to encrypt the
> > secure HTTP state management information using TLS.  So, the draft now
> > provides a web server with both the option to use HTTP (and Diffie
> > Hellman) to establish a secret key, or use TLS to exchange the key.
> >
> > We look forward to your comments on draft -03:
> > http://tools.ietf.org/html/draft-salgueiro-secure-state-management
> >
> > Paul
> 
> 
> --
> Sincerely,
> Yngve N. Pettersen
> ********************************************************************
> Senior Developer		     Email: yngve@opera.com
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
> ********************************************************************