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

[Hannes Tschofenig <[e-mail]>]

Is it correct to summarize the proposal in the following way:

  * The server can encrypt and integrity protect a cookie before it 
sends it to the client.
  * No updates are required on the client side, i.e., the client does 
not perform any cryptographic computation

Ciao
Hannes

On 10/20/2012 12:29 PM, Tobias Gondrom wrote:
> 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
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag