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

["Paul E. Jones" <[e-mail]>]

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

> -----Original Message-----
> From: Yngve Nysaeter Pettersen [mailto:[e-mail]]
> Sent: Friday, July 02, 2010 10:38 AM
> To: 'Gonzalo Salgueiro'; [e-mail]; Paul E. Jones
> Subject: Re: [http-state] draft-salgueiro-secure-state-management
> 
> 
> 
> 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]
> ********************************************************************