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

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 01 Jul 2010 18:54:35 +0200

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 <[email-masked]>  
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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Jul 2010 00:08:19 -0400

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:[email-masked]]
> Sent: Thursday, July 01, 2010 12:55 PM
> To: 'Gonzalo Salgueiro'; [email-masked]; Paul E. Jones
> Subject: Re: [http-state] draft-salgueiro-secure-state-management
> 
> Hi,
> 
> > 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.
> >

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 02 Jul 2010 16:38:22 +0200

Using the key extractor means that the key is clearly associated with the  
endpoint and its certificate.

IMO your design is exactly the kind of thing the extractor was intended  
for.

It also means that you do not have to use the HTTP headers for  
transferring the keydata (except perhaps some kind of nonce), does not  
have to establish a default DH key, and saves an extra roundtrip for  
establishing the key since both parties already have the necessary data,  
in the form of the master secret.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 6 Jul 2010 16:21:40 -0400

Yngve,

I'll confess that I'm not an expert on how the key exporter function works.
So, if we want to use RFC 5705, I may need some help with the details.

That said, if it's not clear, DH is not used at all if TLS is used.  DH is
only there as an option when negotiating a key via HTTP.  When TLS is used,
the key is simply passed over the wire through the response to whatever HTTP
request is issued.  They key would be some random number of the server's
choosing.

Doing anything at the TLS level seems like it would make things a bit
complex.  I would easily create a script (Perl, Python, etc.) to implement
the secure cookie functionality as the draft is presently written.  However,
it's not clear to me how one could implement this on the server if we use
RFC 5705.

So, is there really an advantage?  And how would RFC 5705 be implemented in
practice in a typical web server like Apache?  Would this also introduce
hurdles for the browsers?  I assume not, since you work at Opera :-)  But,
what about tools like curl?  I'd like something that can be easily
implemented by all clients and servers.

Paul

> Sent: Friday, July 02, 2010 10:38 AM
> > 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.
> >
> > * Removes the overhead caused by establishing an independent key
> > agreement protocol
> > 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
> >
> >> 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.
> >>
> >> > 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