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

"Paul E. Jones" <> Sat, 20 February 2010 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D01163A7FAF for <>; Sat, 20 Feb 2010 12:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ph7qZneOqYB5 for <>; Sat, 20 Feb 2010 12:57:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 40EA53A7572 for <>; Sat, 20 Feb 2010 12:57:25 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o1KKw18W008945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Feb 2010 15:58:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1266699486; bh=u4LmisPRNNFWP4kSlzS42cku0REJdw/riitCWshFHwU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=G8u8BxI9M45g9nqEUyGXGQ7g5nNG6j2cniC1wC/GUadO9IX/KKlb12VLToxz1MXRJ 6iwvkrV/ZHv+e7jnWWVEMIlo9eICN6E+KPxkP9N+Zu/j3R8DZk+cQ73hUZDDm6iCZx HBnzZuOZ7F3raSgkX0Ff2WOgMtPBfJtBeYbtM1aQ=
Received: from sydney ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o1KKvs8U016129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Feb 2010 15:57:54 -0500
From: "Paul E. Jones" <>
To: "'Adam Barth'" <>, "'Gonzalo Salgueiro'" <>
References: <> <>
In-Reply-To: <>
Date: Sat, 20 Feb 2010 15:57:43 -0500
Message-ID: <004f01cab26f$5c4796f0$14d6c4d0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acqxr2Z3Zma0UpvaTSaZqb6ROXXOqAAtdF9A
Content-Language: en-us
Subject: Re: [http-state] draft-salgueiro-secure-state-management
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Feb 2010 20:57:26 -0000


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

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

> Adam
> On Thu, Feb 18, 2010 at 3:45 PM, Gonzalo Salgueiro <>
> wrote:
> > Folks -
> >
> > I have posted the following draft:
> >
> >
> >
> > 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:
> >
> >
> >