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

[Tobias Gondrom <[e-mail]>]

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:
> 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.
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag