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

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

Yes (2012-11-09)
No email
send info
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.
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection (2012-11-13)
No email
send info
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
<http://www.ietf.org/mail-archive/web/saag/current/msg04049.html> particularly useful in evaluating this conflict review response, especially messages
<http://www.ietf.org/mail-archive/web/saag/current/msg04129.html> and
<http://www.ietf.org/mail-archive/web/saag/current/msg04164.html>.
No Objection ()
No email
send info
No Objection ()
No email
send info
No Objection (2012-11-14)
No email
send info
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.
No Objection (2012-11-12)
No email
send info
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.
No Objection (2012-11-12)
No email
send info
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.
No Objection ()
No email
send info