IETF conflict review for draft-secure-cookie-session-protocol
conflict-review-secure-cookie-session-protocol-00
Yes
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Barry Leiba Former IESG member
Yes
Yes
(2012-11-09)
Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2012-11-13)
Unknown
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>.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2012-11-14)
Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-11-12)
Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-11-12)
Unknown
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.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown