IETF conflict review for draft-secure-cookie-session-protocol
conflict-review-secure-cookie-session-protocol-00

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-secure-cookie-session-protocol@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-secure-cookie-session-protocol-08

The IESG has completed a review of
draft-secure-cookie-session-protocol-08 consistent with RFC5742.


The IESG has no problem with the publication of 'SCS: Secure Cookie
Sessions for HTTP'  as an
Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
websec and httpbis working groups, but this relationship does not prevent
publishing.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
No objections to publication.

Two questions that I hope the authors might consider:

1) I'm just kind of throwing this one out there: Recently there's been some attacks against the use of compression and encryption.  Is this susceptible to the CRIME-like attacks?

2) In a coupe of places you discuss multiple servers and server pools.  If the server is the only "actor" but now there's more than one "actor" then you're sharing the keys around - right?  Where's that mechanism described and where's the security consideration about sharing the key around?

And some nits on the draft:

s3.2.2: Need reference for AES-CBC-128

s3.2.2: Shameless plug an RFC on appropriateness of HMAC-SHA1: RFC 6194.

[Ballot comment]
Following the idea in Stephen's comment, I encourage the authors of this draft to further clarify that this is documenting an existing, deployed concept.

I found the thread at
particularly useful in evaluating this conflict review response, especially messages
and
.

[Ballot comment]

I agree with the idea of putting in the company name.
But other distinguishers would also be fine, the idea
is just to make it clear somehow that this isn't an
IETF piece of work, since its reasonably likely that
a future IETF piece of work might look quite similar
as this is a reasonable thing and an IETF standard
might well not differ much at all.

[Ballot comment]
If it is a company protocol I agree with Barry, but given the open source code availability, it is not clear whether this is proprietary, or open/public. I am confident that the ISE will make the right call on this.

[Ballot comment]
The authors are asked to please add the company name to the title, and to adjust the abstract and introduction to make it clear that this is their company's proposal, presented for the community's information.

The draft draft-secure-cookie-session-protocol-08.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Abstract:
This document provides an overview of SCS, a small cryptographic
protocol layered on top of the HTTP cookie facility, that allows
its protocol layered on top of the HTTP cookie facility, that
allows its users to produce and consume authenticated and encrypted
cookies, as users to produce and consume authenticated and
encrypted cookies, as opposed to usual cookies, which are
un-authenticated and sent in clear text.

It was reviewed by Jim Schaad, who gave Thomas quite a long list of
things to improve. He's done that, Jim and I agree that it's ready
for IESG review.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org