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

[Tobias Gondrom <[e-mail]>]

Hi Thomas,

On 22/10/12 12:44, Thomas Fossati wrote:
> Hi Tobias,
>
> On Sat, Oct 20, 2012 at 10:29 AM, Tobias Gondrom
> <[e-mail]> 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 :-)
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.

>
>> 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.
> I don't get exactly what you mean here: is it whether the use case for
> SCS actually exists ?
Yes.
>> - 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.
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...)
>> 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.
> 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.
Yes.

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

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