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

["Yngve Nysaeter Pettersen" <[e-mail]>]

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.


On Fri, 02 Jul 2010 06:08:19 +0200, Paul E. Jones <[e-mail]>  
wrote:

> 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:[e-mail]]
>> Sent: Thursday, July 01, 2010 12:55 PM
>> To: 'Gonzalo Salgueiro'; [e-mail]; 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  
>> <[e-mail]>
>> 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: [e-mail]
>> Opera Software ASA                   http://www.opera.com/
>> Phone:  [phone]              Fax:    [phone]
>> ********************************************************************
>


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************