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

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

Yngve,

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

I would like to hear other opinions on this, but it seems like this one is
not really an issue.  The important thing is to ensure we have proper
values, but the clients will use random numbers that will be extremely
challenging even with knowledge of these two values, I think.

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

I understand.  Requests over a separate connection would require a separate
association.
 
> 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.

This is really important feedback.  Clearly, we don't want to create a
burden for either the client or server.  I had assumed that the cookie value
(unencrypted) would be maintained globally as it is today.  Each tab,
though, or each thread that issues separate requests would establish its own
association.

In the simplest case, an association could be established with each tab and
the association data could be discarded when closed.  Would that approach
help?

I would prefer to cache the association data for a longer period of time (24
hours?) and have a mechanism to prevent two requests from using the same
value at the same time, but I am more interested in making this simple.

> >> 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 [not] 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.

Given that TLS is not universally employed, even by companies that have the
resources to do it (like Facebook), does that not provide you with
sufficient evidence that we should take steps to protect end-users with
something better than nothing?  I think we should, but I guess you disagree.

> >> 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.

We will.  It seems we need to consider both a means of exchanging a key via
DH and TLS.

Paul