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

[Thomas Fossati <[e-mail]>]

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

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

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

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

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