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

Thomas Fossati <> Tue, 23 October 2012 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC3D421F8666 for <>; Tue, 23 Oct 2012 00:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05+Kt68uT3Q1 for <>; Tue, 23 Oct 2012 00:52:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B4D2721F866F for <>; Tue, 23 Oct 2012 00:52:43 -0700 (PDT)
Received: by with SMTP id s14so2381559qcg.31 for <>; Tue, 23 Oct 2012 00:52:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vIq3CbHh8LKVnhmTk3meybe7F2pbblN2QANTdZbTIYo=; b=lRm17OQ887gxcy7i8EKQ3F62WCJLPChZc8Z5RJ51yVZV/Agn582txZs+PYfmSqZE05 isEG0v0W9dv5MMS0sYaRU8dyz2vW4sZgupnJoCzs6KrlFe0TnqvnUFpCSumqsnYsYfM0 aEa/uYGaUU6izgNANYDhiWskZDZ/QeCHqEi7dLI8mwo/DGIzYayAp3G4chNkNjXGDCvp Pm7NgKJg8FmaKilyVak5nRPlEgxB9qxSn4sJto4tUT5sZVeVX++ciHorqD68V+Mxu3D5 Tl7nl8VNlleU6M3n1O+0WA8s6YXKvp9UnYZ7oIw+wQTKgvijOosQsLojeuuyXkJrcl4s NLgw==
MIME-Version: 1.0
Received: by with SMTP id bf25mr1359033qcb.4.1350978762967; Tue, 23 Oct 2012 00:52:42 -0700 (PDT)
Received: by with HTTP; Tue, 23 Oct 2012 00:52:42 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 23 Oct 2012 08:52:42 +0100
Message-ID: <>
From: Thomas Fossati <>
To: Tobias Gondrom <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQku7du5B/Mmm5Xq2T9z0JDplCisYM7KzMvFca0icuVTZZIBoA63rtEtSPO6Mv8j3oa9w7Du
Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2012 07:52:45 -0000

Hi Tobias,

On Mon, Oct 22, 2012 at 7:10 PM, Tobias Gondrom
<> 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.