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

[Thomas Fossati <[e-mail]>]

Hi Tobias,

On Mon, Oct 22, 2012 at 7:10 PM, Tobias Gondrom
<[e-mail]> wrote:
> 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...)

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

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