Subject: [saag] Input for conflict review of draft-secure-cookie-session-protocol

From: Thomas Fossati <[email-masked]>
Date: Fri, 19 Oct 2012 15:32:52 +0100

Hi Tobias,

>> - Should this be handled by an existing working group?  Which one?
> Yes.

A little bit of context, to hopefully give everyone the reasons why
and how we are here.

SCS was presented for the first time (to get expert review/feedback)
to IRTF CFRG in September 2006:

  http://www.ietf.org/mail-archive/web/cfrg/current/msg01307.html

Then after a long pause, I brought it to the IETF (http-state WG) in
February 2011:

  http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html

where I've tried to propose it as a working group item, with no avail.
(Please note that this pre-dates JOSE BoF which was held in March 2011 IIRC.)

So, the natural outcome was to go through ISE, which I've done in December 2011.

In these years, in different occasions it has received extensive
review by a couple of well known and respected security guys -- David
Wagner and Jim Schaad.

The whole shebang is nothing new, just a simple bearer token format
which is suitable for use in HTTP (in cookies and URIs, or any other
HTTP header value).  With the added value that it can be traced back
to a provably secure authenticated encryption scheme.

I've taken the trouble to publish as I though it could provide a solid
and reusable building block for developers, that, as a bonus, are also
given a reference open-source implementation.

The Security Consideration has plenty of material about the possible
risks and related countermeasures / mitigations.  If there's something
that really needs to be said and it's not already there, please state
it precisely and I'll do the needed editing.

I like to hear solid technical comments, I really like it, and I'm
totally open to modify the I-D as long as the proposed modifications
makes it a better document.  This is the sole purpose of going through
the IETF process, after all.

Thanks, Thomas.

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 20 Oct 2012 10:29:02 +0100

Hi Thomas,

thank you for providing the background about this.
Obviously I didn't know about the IRTF CFRG, as I did not attend that 
IRTF group meeting at the time.
And I can imagine it can be quite frustrating for you having to explain 
the history and your draft again and again to the different audiences 
and groups over the years. ;-)

Maybe some thoughts on why I think this would benefit from IETF review:
I can see the underlying idea and understand the potential use case of 
storing state on the client in an encrypted container.

However, I see quite a few potential issues that could arise with this 
draft. I am not saying "don't do it", all I am saying is that I really 
think this deserves IETF review (either in saag, or even better an IETF 
WG (not IRTF).

Just as an example: already the very first sentence in the introduction 
some assumptions are half-true/half-false (like e.g. that cookies would 
be "... un-authenticated and sent in clear text." In many applications 
(though not all of them) cookies are in fact transmitted over HTTPS and 
in an authenticated session and not in clear-text...)

A number of questions with this drafts make me suggest that IETF review 
is a good thing (including the question whether IETF wants to do this at 
all):
- is the underlying use case valid for the draft? I am not sure of that.
- the text of the draft would hint towards status as Experimental, not 
as Informational? Why Informational?
- Is there the vision of interoperability between different 
implementations for this?

Please note, that I don't deny at all, that there is a security 
considerations section - and in the case of this draft, I actually like 
that it is quite detailed on security implications compared to some 
other drafts I've reviewed in the past years, but I would question 
whether in fact suggesting to store server state only in a client is a 
good idea at all, as it opens quite a number of security problems.

All this leads me to the recommendation to apply IETF review for this 
draft to avoid trouble.

However, this is only IMHO, for you, saag and the ADs to consider. And I 
have the highest regard for Jim and our other reviewers. So consider 
this just as my 5cents and I will hand over to others on saag (including 
Jim) to comment and decide on whether we should give this more IETF 
review or not...

Best regards, Tobias

On 19/10/12 15:32, Thomas Fossati wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 20 Oct 2012 13:17:14 +0300

Is it correct to summarize the proposal in the following way:

  * The server can encrypt and integrity protect a cookie before it 
sends it to the client.
  * No updates are required on the client side, i.e., the client does 
not perform any cryptographic computation

Ciao
Hannes

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 22 Oct 2012 18:44:52 +0100

Hi Tobias,

On Sat, Oct 20, 2012 at 10:29 AM, Tobias Gondrom
<[email-masked]> wrote:
> Just as an example: already the very first sentence in the introduction some
> assumptions are half-true/half-false (like e.g. that cookies would be "...
> un-authenticated and sent in clear text." In many applications (though not
> all of them) cookies are in fact transmitted over HTTPS and in an
> authenticated session and not in clear-text...)

right, I will rephrase this to avoid the half wrong side of the statement :-)

> A number of questions with this drafts make me suggest that IETF review is a
> good thing (including the question whether IETF wants to do this at all):

I don't get exactly what you mean here: is it whether the use case for
SCS actually exists ?

> - the text of the draft would hint towards status as Experimental, not as
> Informational? Why Informational?
> - Is there the vision of interoperability between different implementations
> for this?

In case there are multiple servers (e.g. a set of proxies that have to
decide if the cached video can be served to the requesting UA), and
they are from multiple vendors, yes.

> considerations section - and in the case of this draft, I actually like that
> it is quite detailed on security implications compared to some other drafts
> I've reviewed in the past years, but I would question whether in fact
> suggesting to store server state only in a client is a good idea at all, as
> it opens quite a number of security problems.

I'm not unaware of that, and I'm not suggesting to use SCS everywhere
on every occasion, ignoring the inherent risks.  As I've already said
to Willy in a private exchange, I think your concerns could be solved
by adding the text that you think is currently missing in the Security
Consideration.  And, much likely, adjusting the Introduction too.
That would make it a better (and safer) document.

I share the vision that, say, online banking is not the right use case
for "pure" SCS (i.e. without a bit of state on server but the crypto
keys), but we can't pretend that online banking is the only playground
for cookies/ authorisation tokens in the web.  Likewise, I don't
pretend the HTTP interface to a diskless home router is the most
important application on the face of earth :-)  Yet, someone in the
digital content distribution market would tell you that SCS/SCS-like
mechanisms are in massive use today, on STBs and other kind of
non-browser UAs...

> All this leads me to the recommendation to apply IETF review for this draft
> to avoid trouble.
>
> have the highest regard for Jim and our other reviewers. So consider this
> just as my 5cents and I will hand over to others on saag (including Jim) to
> comment and decide on whether we should give this more IETF review or not...

Thank you very much for taking the time to argument your point.
Discussion is vital. Yet, I'm quite surprised that a simple silly
thing like SCS has raised such a level of reactions.  As Stephen
gently suggested, I've probably made a bad marketing choice in picking
the name.  Avoiding the use of the cookie+secure combo in the title (a
gross oxymoron now that you make me think about it) would have
probably made my life easier :-)

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 22 Oct 2012 13:10:28 -0500

Hi Thomas,

> right, I will rephrase this to avoid the half wrong side of the statement :-)
Yes, changing the intro would help as this frames the way people see 
what this should be used for.

And the intended status is also worth discussion.

Yes.
> they are from multiple vendors, yes.
That might be a use case to explore as justification for the draft. As 
interoperability of different implementations would be a reason to write 
this down. (otherwise people could equally do proprietary 
implementations...)
Yes.

> mechanisms are in massive use today, on STBs and other kind of
Ok. These use cases might be worth referencing/adding in the appendix, 
and framing what SCS is intended for.
> probably made my life easier :-)

Actually I don't think the draft is "silly" nor a bad "marketing" 
choice. And I think the title reflects correctly what's in the tin. So 
the title is accurate.

Maybe to explain one further bit, why this rang some bells (alarm bells 
that is):
In any server implementation, I always advise that people must never 
trust content from the client. And that at the least you must verify all 
client input for range, type etc. And in a good implementation the 
server shall store the state and only allow the client to link to that 
state by reference. Client data is outside of the control of the server 
and can be lost, corrupted, manipulated on the way or even intentionally 
malformed by an authorised client/UA to screw things up. This can lead 
to data leakage, corruption of server data, or in simple cases also to 
fostering DoS by CPU costs on the server due to de-/encryption algorithm 
CPU times. So a server must never trust client data or client state (and 
IMHO use client-side state data as little as possible). And SCS is 
basically going against this underlying security paradigm, which is 
giving me some worries.

I understand that SCS could mitigate some of the risks above, but I have 
some concerns that SCS might open up a whole can of worms when we go 
down the path of client-side state - and that if something breaks with 
SCS, it may break in a very bad way...

Tobias

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 23 Oct 2012 08:52:42 +0100

Hi Tobias,

> this down. (otherwise people could equally do proprietary

Which includes all the use cases except the mere "web interface to the
diskless router".

> Ok. These use cases might be worth referencing/adding in the appendix, and
> framing what SCS is intended for.

The introduction already mention that:

  "Another noteworthy application scenario is represented by the
   distribution of authorized web content (e.g. by CDNs), where an SCS
   token can be used, either in a cookie or embedded in the URI, to
   provide evidence of the entitlement to access the associated resource
   by the requesting user agent."

> Maybe to explain one further bit, why this rang some bells (alarm bells that
> is):
> In any server implementation, I always advise that people must never trust
> content from the client. And that at the least you must verify all client
> input for range, type etc. And in a good implementation the server shall
> store the state and only allow the client to link to that state by
> reference. Client data is outside of the control of the server and can be
> lost, corrupted, manipulated on the way or even intentionally malformed by
> an authorised client/UA to screw things up. This can lead to data leakage,
> corruption of server data, or in simple cases also to fostering DoS by CPU
> costs on the server due to de-/encryption algorithm CPU times. So a server
> must never trust client data or client state (and IMHO use client-side state
> data as little as possible). And SCS is basically going against this
> underlying security paradigm, which is giving me some worries.

I think poor SCS has been misunderstood here :-)

The "state" (or whatever the server puts into the DATA atom) is
encrypted, timestamped, and attached a proof of authorship by the
server.  No client -- intentionally or unintentionally -- can screw
things up without being noticed, unless of course she possesses the
private server keys (but this is a completely different story).

So, no data leakage, nor corruption is possible with SCS (this was in
fact a design goal).  The only really different thing (whose impact is
described in Sect. 8.2.2.) is the voluntary deletion of an SCS cookie
by the client.

As to the possible resource DoS, it would be spotted very early by the
"inbound transform" (Sect. 3.2.6) after just applying a Base64
decoding and one HMAC on a typically slim input -- a really negligible
demand in terms of memory/cpu, even for an embedded devices which,
BTW, is already keeping the TCP context, parsing HTTP headers, etc.

Cheers, Thomas.