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

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

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

> -----Original Message-----
> From: Yngve N. Pettersen (Developer Opera Software ASA)
> [mailto:[e-mail]]
> Sent: Friday, March 12, 2010 6:08 AM
> To: Paul E. Jones; 'Gonzalo Salgueiro'; [e-mail]
> Subject: Re: [http-state] draft-salgueiro-secure-state-management
> 
> On Fri, 12 Mar 2010 08:57:26 +0100, Paul E. Jones
> <[e-mail]>
> wrote:
> 
> >> Section 4:
> >>
> >> * It is not a good idea to have default g and p values
> >
> > Why?  I've seen this done a number of times with various protocols,
> and
> > they're certainly not secret values.
> 
> Mostly I am concerned about being able to use prior knowledge about
> what
> the client uses to weaken security
> 
> >> * 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.
> >
> > This is the reason for having an "association".  Each parallel
> request
> > would
> > establish its own, separate association.  There would never be two
> > requests
> > in parallel using the same assoc value.
> 
> The parallel requests I am primarily referring to are, for example,
> inline
> resource requests (for images, scripts, etc.) sent across multiple
> parallel connections, and which can be sent pipelined. Clients seldom
> keep
> just one connection open to a server that have several resources the
> client needs.
> 
> BTW, about separate tabs having separate associations: Opera, at least,
> does not normally separate URLs in tabs from each other, except in
> special
> situations like the Private Mode. Tabs normally share the cookies,
> including document.cookie cookies, and it would IMO not be practical to
> add this as a special case.
> 
> >> 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.
> >
> > You're correct, but that was our objective.  TLS is excellent when we
> > wish
> > to secure everything end-to-end.  Without TLS, there is absolutely no
> > security at all.  In our opinion, there is a need to prevent passive
> > attacks
> > from taking place so trivially.
> 
> That may be, but only targeting passive attackers is IMO not enough of
> a
> reason for this, particularly when TLS can be used to avoid both that
> type
> of attacker and the active attacker.
> 
> >> 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.
> >
> > A possible solution to this is to use TLS to perform the DH operation
> > *or*
> > to simply send the key over the wire from the server.  So, if a web
> site
> > (e.g., Facebook) wanted to secure the login process and ensure there
> was
> > no
> > possibility of a MiM could intercept the key, it could design the
> system
> > in
> > that way.  The balance of the traffic, though, could be exchanged in
> the
> > clear and the session served to the right user based on the encrypted
> > cookie
> > passed on the wire.
> 
> Possible. See my comment about using TLS extractor for key-agreement,
> which would eliminate the separate DH operation, and implicitly protect
> the operation against passive and active attackers, as long as they are
> not able to attack the SSL connection.
> 
> 
> 
> --
> Sincerely,
> Yngve N. Pettersen
> 
> ********************************************************************
> Senior Developer                     Email: [e-mail]
> Opera Software ASA                   http://www.opera.com/
> Phone:  [phone]              Fax:    [phone]
> ********************************************************************
>