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

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Oct 2012 07:15:03 -0400

> [email-masked] was one group NOT included in your email asking for conflict review.

Thanks; I will correct that now.

Barry

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Oct 2012 16:08:22 +1100

Barry,

draft-secure-cookie-session-protocol-08 is fairly close to the IETF JOSE working group’s JSON Web Encryption (JWE) format [draft-ietf-jose-json-web-encryption].

draft-secure-cookie-session-protocol-08:
* a smallish text string with confidentiality and integrity protection; as does JWE
* symmetric key; which is one JWE option
* arbitrary binary content; same as JWE
* uses base64url encoding; same as JWE
* uses "|" as a separator; JWE uses "."
* deflate compression; same as JWE
* includes the time; signing-time field has been proposed for JWE
* single id indicates keys and algorithms; JWE has separate alg id, and (broken) key id
* 

As to whether draft-secure-cookie-session-protocol-08 “could potentially disrupt the IETF work done in WG” JOSE… uhmm. Probably not.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, 18 October 2012 1:25 PM
> To: [email-masked]; [email-masked]; [email-masked]; apps-
> [email-masked]; [email-masked]
> Subject: [apps-discuss] Input for conflict review of draft-secure-
> cookie-session-protocol
> 
> A document titled "Secure Cookie Sessions for HTTP" has been submitted
> to the Independent Stream Editor (ISE):
> http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/
> 
> The IESG has been asked to review the document, as specified in RFC
> 5742, Section 3.  The Security and Applications Area Directors are
> looking for input for that review.  Please post any relevant comments
> to the Security Area list, <[email-masked]>, as soon as possible, and at
> least by 1 November 2012.
> 
> Note: Please do NOT post responses to any of these mailing lists.
> Respond only to <[email-masked]> (using the subject line of this
> message).
> 
> Please read RFC 5742, Section 3, and be aware that we are not looking
> for detailed comments on the document itself (see below).  We
> specifically need input on whether this document is in conflict with
> work that's being done in the IETF.  Look at the five possible
> responses specified in that section, and help us determine whether any
> of 2 through 5 applies.  Please be specific in your response.
> 
> In addition to this, we're sure that the authors and the ISE would
> appreciate comments about the document.  If you have those, you may
> send them directly to the authors at <draft-secure-cookie-session-
> [email-masked]>
> and to the ISE at <[email-masked]>.
> General discussion of the document on these lists or the saag list will
> likely not get to the authors or the ISE.
> 
> Barry Leiba, Applications AD
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Oct 2012 08:48:05 +0200

Hello,

I just checked the following document and have one main concern :

> http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/

Section 3.3.1.1. mandates the use of the Expires field :

   SCS cookies MUST include an Expires attribute which shall be set to a
   value consistent with session_max_age.

This means that these cookies will necessarily be stored, they're not
just session cookies that expire at the end of the browsing session.

But later it is clearly stated in section 8.2.1 that nothing is possible
to prevent a stolen cookie from being replayed. This is a big concern
because with normal cookies where the server owns the state, the user
just has to logout when he suspects a cookie disclosure, this causes
his session to terminate and the associated cookie cannot be used anymore.

With SCS, it looks like when the user knows his cookie has been stolen,
all he can do is wait for its maximum life time to expire.

Right now stolen cookies are the main security issue on the web. Banking
applications have to live with malware which steal user cookies so that
other people can remotely browse on their account. Some malware even do
the work in parallel with the user, or wait for the user to become idle
to do some operations before he closes the browser.

With SCS, it looks like the malware will not need to install in the browser
anymore, it will just have to steal the stored cookie and use it at any
time even when the browser is closed, since the user has no way to revoke
it.

Hence, I'm failing to see what specific use case this protocol covers,
however I see a risk that it is adopted by users who don't completely
understand its security implications. The focus is clearly set on how
the cookie contents are secured but not that much on what it should or
should not be used for.

Regards,
Willy

PS: please CC me in responses, I'm not subscribed to saag@.

---

From: SM <[email-masked]>
Date: Thu, 18 Oct 2012 09:37:35 -0700

Hi Willy,
>the cookie contents are secured but not that much on what it should or

The draft is supposed to be published through in the Independent 
Submissions stream.  What that means is that the document won't be an 
IETF specification or IETF "standard".  The question was whether the 
document conflicts with existing IETF work as the publication of the 
document as a RFC might be blocked or a note might be added to it.

A conflict review does not get into whether a protocol is "good" or 
"bad".  It may be better to send the above comment to 
[email-masked]

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Oct 2012 13:03:02 -0400

> I just checked the following document and have one main concern :
...
> understand its security implications.

> of 2 through 5 applies.  Please be specific in your response.

Your response is not related to whether this conflicts with existing
IETF work, but is addressing issues in the document.  You need to take
these up with the authors and the Independent Stream Editor.  Again
from my note:

> send them directly to the authors at
> <[email-masked]>

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Oct 2012 13:22:38 -0400

> Well, maybe it's a matter of point of view. Adam took great care to
> rework the cookie spec and achieve RFC6265 with a number of usage
> recommendations to use cookies in the safest way. Since this draft
> suggests a usage which seems totally insecure to me, I found it
> appropriate to raise it as conflicting with the intended use of
> cookies. Maybe I was wrong, and if so please accept my apologises.
> Then it's unclear to me what kind of conflict should be raised :-/

True, and it's sometimes unclear to us as well.  I'll see your :-/ and
raise you a :-(

What we're looking for is this sort of thing:
- Is this document in direct conflict with current work in a working
group?  Which one(s)?
- Should this be handled by an existing working group?  Which one?
- Should a new working group be chartered for this, rather than doing
it as an Independent Submission?
- Does it appear that the authors are trying to get around the system
by submitting this to the ISE?
- Is this spec proposing something sufficiently harmful that it needs
proper IETF review to fix it?

I suppose your comments could be arguing for that last one.

But look at the list in RFC 5742, Section 3, and comment here on which
of the five responses you think applies to this document.  And then
definitely give your other feedback on the document to the ISE and the
document authors.

Thanks, Willy.

Barry

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 18 Oct 2012 21:37:33 +0100

Hello,

after a brief review of the draft, I got quite a bit of headache with 
this draft.
Answers inline.

Tobias

> - Is this document in direct conflict with current work in a working
Not to my knowledge. (talking about websec)
But it may be in conflict with use cases for cookies.

> - Should this be handled by an existing working group?  Which one?
Yes. IMHO this is actually very dangerous stuff. The implied use 
case/proposal is to not store state on a server at all and store and 
trust it on the client only, which would be a major paradigm shift. And 
actually would go against many security recommendations I have given and 
received in the past.

> it as an Independent Submission?
No. No new WG, but I think we should try to fit it into one of the 
existing working groups.
> proper IETF review to fix it?
Yes. As explained above: In my view this can be playing with fire.
I believe such a paradigm deserves (and needs) IETF review.

> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Oct 2012 19:11:29 +0200

Hi Barry,

On Thu, Oct 18, 2012 at 01:03:02PM -0400, Barry Leiba wrote:
> IETF work, but is addressing issues in the document.

>  You need to take

OK I will resend there then.
Thanks and sorry for the confusion.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Oct 2012 19:41:13 +0200

On Thu, Oct 18, 2012 at 01:22:38PM -0400, Barry Leiba wrote:
> True, and it's sometimes unclear to us as well.

OK that makes me feel more comfortable now :-)

> I'll see your :-/ and raise you a :-(
> 

Yes, seems appropriate.

> of the five responses you think applies to this document.

I'm balanced between 3 and 5 :
  3. The IESG has concluded that publication could potentially disrupt
     the IETF work done in WG <X> and recommends not publishing the
     document at this time.

  5. The IESG has concluded that this document extends an IETF protocol
     in a way that requires IETF review and should therefore not be
     published without IETF review and IESG approval.

Basically if used as general purpose cookies, the impossibility to ensure
non-replay would be a no-go for me as it goes against the principles of
RFC6265, hence #3.

However, if designed for use in very specific cases I'm not aware of, then
probably the document needs some editorial adjustments to clearly indicate
that it is not for general use and possibly be reviewed by specialists to
ensure nothing was left unchecked, hence #5.

> And then

Done.

> Thanks, Willy.

You're welcome.

Cheers,
Willy

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 22 Oct 2012 17:02:04 +0100

Hi Willy,

> non-replay would be a no-go for me as it goes against the principles of

I beg to disagree.  6265 states:
  "Servers SHOULD encrypt and sign the contents of cookies (using
   whatever format the server desires) when transmitting them to the
   user agent (even when sending the cookies over a secure channel)."
which is the very essence of what SCS does (adding a timestamp too).

No imposition is made by SCS on storing the whole application state in
the cookie, it is just left as a possibility, which comes in handy in
some specific scenarios -- e.g. the home router that can reboot
without asking the admin to re-authenticate.

In fact, if the server wants, it can use the DATA atom to just store a
session id which points to state archived server side, and use SCS to
just "encrypt and sign the contents of cookies"

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 09:31:30 +1100

As far as I can tell, this document specifies some extensions to the Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined cookie names. It's hard to tell, both because of how the draft is written, and because I read it very quickly.

6265 doesn't define how it's to be extended very well (possibly because the underlying assumption is that extensions are VERY difficult to deploy). However, the precedent of an independent stream RFC defining such extensions, or worse "squatting" on the cookie name space (which is very widely used and thus very difficult to guarantee an absence of conflict) is concerning.

It seems to me that this *might* therefore conflict with the (previous) HTTPSTATE WG's work. 

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 23 Oct 2012 22:53:49 +0100

Hi Mark,

On Mon, Oct 22, 2012 at 11:31 PM, Mark Nottingham <[email-masked]> wrote:
>
> As far as I can tell, this document specifies some extensions to the Cookie / Set-Cookie (RFC6265),

SCS doesn't define any extension whatsoever.  It just specifies a
format for what 6265 already identifies as a security need for "plain"
cookies. From RFC 6265, Section 8.3.:

   Servers SHOULD encrypt and sign the contents of cookies (using
   whatever format the server desires) when transmitting them to the
   user agent (even when sending the cookies over a secure channel).

> and/or "squats" on some pre-defined cookie names.

No name squatting: ANY_COOKIE_NAME in Section 3.3. of SCS is just a
placeholder which really means what it says: any name the cookie maker
decides to uses.

> 6265 doesn't define how it's to be extended very well (possibly because the underlying assumption is that extensions are VERY difficult to deploy).

Sorry if I sound like a broken record, but I want to be ultra-clear on
this point: SCS is not an extension to the cookie exchange; and in
fact it works out of the box -- today and since 6 years now -- on any
browser with cookies enabled.

Cheers, Thomas.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Oct 2012 01:47:08 -0400

MNot says...
> As far as I can tell, this document specifies some extensions to the
> Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined
> cookie names. It's hard to tell, both because of how the draft is written,
> and because I read it very quickly.

I don't see any extension there.  I see it using the cookie mechanism
defined in 6265, and specifying how to use encrypted cookies instead
of plain-text ones.

> It seems to me that this *might* therefore conflict with the (previous) HTTPSTATE WG's work.

I have sympathy for that idea, but it doesn't bear out:

The authors proposed it to the httpstate WG on 22 Feb 2011:
http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html

They followed up on 25 Feb and 7 March:
http://www.ietf.org/mail-archive/web/http-state/current/msg01247.html
http://www.ietf.org/mail-archive/web/http-state/current/msg01268.html

On 13 March they tried to get on the agenda for the Prague IETF meeting:
http://www.ietf.org/mail-archive/web/http-state/current/msg01277.html

That didn't happen, and the working group was closed in May 2011,
after the publication of RFC 6265:
http://www.ietf.org/mail-archive/web/http-state/current/msg01317.html

The only responses to any of their messages were two from Adam Barth
in the first (22 Feb) thread.  There appears to have been no interest
in taking on the work in httpstate.

What that says to me is that httpstate had the chance to take it, and
opted out.  It's not valid to now say that they should have, and this
document conflicts.

All that said, here's what I think, as the AD who's shepherding this
through the conflict review:

1. It's probably acceptable to do this through the ISE -- that is,
this probably does not *conflict* with IETF work.

2. It's probably better to do this through the IETF Stream -- it will
get better review and be a more solid document that way.

3. The authors are happy to do it that way; I've talked with them about it.

4. We could charter a new "son of httpstate" working group for this,
we could fit it into an existing working group (httpbis or appsawg,
likely), or we could do it as an AD-sponsored document (I would be
happy to sponsor it, and I suspect Stephen would also).  If we did
that, it would go as Proposed Standard   ... or we could let it
continue through the Independent Stream, as Informational.

Thoughts?

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Oct 2012 15:31:47 +0100

Hiya,

> this probably does not *conflict* with IETF work.

Adding the company name to the title would still be good
here if we take this route I think. (If for no other reason,
to avoid confusion in case we do want a standard flavour of
this later.)

> continue through the Independent Stream, as Informational.

I do think a standard for this could be useful, lots of
sites do emit encrypted/integrity-protected cookies and
probably lots of 'em roll their own badly.

It'd be good to try get a feel for whether a standard would
be likely to be adopted though before going down this route
I think. Not sure how best to get that done though as I guess
it'd more be one for implementers of application frameworks
and toolkits, who probably don't read saag. That might
take a while though.

So, overall, I'd say maybe best might be to stick to
the ISE route for this, to get it done (assuming that's
what the authors would prefer) but then also try figure
out if there's a useful standard to be written here,
which might well start out from this document, or
maybe we'd find out that there're already slightly
different ways to do this that are closer to current
implementations that'd be more likely to get deployed.

For example load balancing might call for slightly
more complex key mgmt, or maybe there'd be a reason
to also encrypt or to omit the ATIME field. I've no
idea if that's the case, but we'd want to figure it
out for a standards track document, and that might
take enough time that the authors would really prefer
to take the ISE route for now.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Oct 2012 15:56:43 +1100

Hi,

If you're finding yourself saying it repeatedly, it might be worth explicitly documenting what the relationship to existing cookies are, what the expectations are for the various parties involved, and giving a bit more information about the use case. 

Cheers,