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

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

Adam,

> Thanks for the interesting read.

Likewise, thanks for reviewing our initial draft.

> This working group is current in "phase one," which is to create a
> specification for the de facto cookie protocol in use today.  In phase
> two, we'll be considering way of improving HTTP state management.
> This document looks like useful input for phase two.

This is reasonable.  What we would like to do is build on the work you're
presently doing. Clearly, we would not want to publish an RFC that describes
any means of encrypting specific pieces of HTTP state management information
without first finalizing the test you're preparing now.
 
> The document isn't entirely clear about what security problem with the
> current cookie protocol you're trying to solve.  It would be helpful
> if you included a threat model and an explanation of your security
> goals.

Agreed.  We probably need a little more background here.  The problem isn't
inherent in the cookie protocol, but the use of cookies for state management
over insecure connection.  What we have found is that many web sites,
including very large sites like Facebook, pass state information in the
clear.  So, what we wish to do is define a way to provide a better level of
security over such connections.

> You argue against using TLS for all HTTP traffic on the basis
> of requiring a different IP for each host name.  This problem will be
> solved in the intermediate term by the SNI extension, which will
> undoubtably beat any improved state management protocol to market.

We didn't mean to argue against TLS, actually.  It is our opinion that if
the application needs strong security, TLS should be used.  However, many
web sites do not need that much security, as virtually all of the content is
available, anyway.  Those include sites like blogs, public news sites, and
many, many others.  What is needed, though, is some level of assurance that
the person who might be posting information or manipulating information is
the authorized user.

It's trivial today for sites that do not use TLS for a rogue entity today to
grab cookies off the wire and transmit messages that post or change content
that is owned by another.  It does not require a "man in the middle" attack,
but merely passive monitoring of traffic.
 
> The document preserves some of the syntax from the cookie protocol.
> I'd advise dumping the current syntax entirely.

Can you elaborate on what you mean here?  It was our intent to build upon
the draft you are writing.  The different is that we introduce a new
Set-DH-Cookie, etc.  What we could do is re-use Set-Cookie and include a new
parameter (similar to the existing "Secure") that would indicate that the
value of the name/value pair ("cookie-value") is encrypted. This might be a
simple parameter like "DH".  The challenge, though, is that we would need a
way to also indicate via the Cookie header that the contents are encrypted.
We could leave that as an exercise for the application to determine, of
course.  The web applications ought to know which cookies it encrypts and
which it does not.

In any case, it is these kinds of discussions that I think are important to
have.
 
> The document seems quite concerned about passive network attackers,
> but doesn't seem that concerned abou the other security issues with
> cookies.  You might consult the Security Considerations section of
> http://tools.ietf.org/html/draft-ietf-httpstate-cookie for a survey of
> security problems a new protocol might improve.  (Note that this
> section will be improved markedly in the next version of the draft,
> which you can see here
> http://github.com/abarth/http-state/blob/master/drafts/cookie.xml).

What we're trying to address in this draft are some of the issues outlined
in the security sections as outlined in your forthcoming draft.  By section:

7.1) Clearly, this draft does not move us away from use of cookies.
Personally, I'm rather fond of cookies, modulo the security concerns
7.2) Embedding information into URLs to manage session state is doable and
many applications also do this.  However, URLs are subject to the same kinds
of attacks and would need the same kinds of protection.  Further, users have
a tendency of copying and pasting URLs, so whatever method is devised would
have to take this behavior into account.  I can't think of a way to avoid a
replay attack when storing session information in URLs (though associating
an IP address has some limited utility).
7.3) This is really a problem and the scope of what we're proposing to
address in our draft.  Using "Set-DH-Cookie" and "DH-Cookie", we get the
simplicity of cookies with the benefit of encryption of sensitive
information.
7.4) This issue is valid with existing cookies and, which our draft provides
a means of encrypting cookie information, the recommendations here should
still be followed, in my opinion.
7.5) This is also sound advice.
7.6) This is likewise sound advice that our draft does not attempt to
address.
7.7) Using DH-Cookie might help address this issue, since the recipient who
has compromised DNS would not be able to decrypt the cookie.

In any case, I fully appreciate that the WG is presently not considering
extensions beyond what is defined today.  Nonetheless, I would hope that we
could work with interested parties who would like to improve on the security
of cookies.  Perhaps the ultimate answer is only using TLS everywhere, but
today cookies are widely used and they really are a very useful extension to
HTTP.

Paul
 
> Adam
> 
> 
> On Thu, Feb 18, 2010 at 3:45 PM, Gonzalo Salgueiro <[e-mail]>
> wrote:
> > Folks -
> >
> > I have posted the following draft:
> >
> > http://tools.ietf.org/html/draft-salgueiro-secure-state-management
> >
> > This draft provides a simple method for providing a reasonable level
> of security when exchanging state management information through HTTP
> in situations where TLS is not employed.
> >
> > We would appreciate receiving any comments you have and input on
> whether you think this might be a complementary addition to the work
> the WG is already undertaking.
> >
> > Thanks,
> >
> > Gonzalo
> >
> >
> >
> > This email may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the
> intended recipient (or authorized to receive for the recipient), please
> contact the sender by reply email and delete all copies of this
> message.
> >
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> >
>