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

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

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]
********************************************************************