Reviewer: Valery Smyslov Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the HTTP cookie protocol. The document is well written and easy to read. The Security Considerations section is mostly taken intact from RFC 6265 (except that considerations for newly introduced SameSite cookies are added), and only overviews "a few of the more salient issues". This is a bit disappointing, I would have expected that more considerations are added based on 14 years experience since RFC 6265 was published. However, I understand that the list of security considerations would have been very long and still hardly complete. Since it seems to be next to impossible to accurately list all the possible cookie exploits, I wil mark the document as "Ready", but with a reservation, that the the Security Considerations section is intentionally not complete and this seems not possible to fix. I still have some easy to address suggestions that I think would be helpful for readers. 1. Please, make it more clear that the restrictions on the cookie use, that the server imposes via attributes, are not guaranteed to be honored even by a honest user agent. For example, if the clocks on the server and on the client are out of sync, then the user agent may innocently try to use cookie beyond its lifetime. Thus, the imposed restrictions for the received cookies MUST be checked by the server. 2. Section 8.1 states that "by default, cookies do not provide confidentiality or integrity from network attackers, even when used in conjunction with HTTPS". In my reading this sounds like HTTPS is useless for cookies security. I think that this needs a clarification. While use of HTTPS cannot prevent network attacks using cookies mounted by other participants in HHTP communications (like cross-site attacks), it does prevent eavesdropping and manipulation of cookies by on-path entities that don't participate in these communications. I believe it should be emphisized that encrypted transport does reduce the attack surface using cookies. 3. Section 8.3 lists security risks when cookies are sent in clear and clause 3 states: "A malicious client could alter the Cookie header before transmission, with unpredictable results". I failed to understand how this is concerned with the use of TLS. In my understanding, malicious clients can do this in any case, regardless on whether TLS is used or not. Am I missing something? 4. Section 7.1, last para states that "it is RECOMMENDED that user agents adopt a policy for third-party cookies that is as restrictive as compatibility constraints permit". This gives no concrete recommendations, and no examples, thus making this requirement vague and subjective. I think this requirement should be provided with more details how to deal with it. Just out of curiosity - the draft adds a requirement that cookie SHOULD NOT be greater than 400 days. I wonder why this particular margin was chosen. Why not 365 days (a year) - it looks like a natural equivalet to "very long, but not infinite"? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
