From: "Valery Smyslov" <valery@smyslov.net>
To: <secdir@ietf.org>
References: 
 <173928072730.554181.11643604175051228621@dt-datatracker-75c44cbbdf-pxnd6>
In-Reply-To: 
 <173928072730.554181.11643604175051228621@dt-datatracker-75c44cbbdf-pxnd6>
Date: Thu, 18 Sep 2025 14:38:51 +0300
Message-ID: <0b1901dc2890$d0e2abf0$72a803d0$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: ru
Thread-Index: AQFcxNKZV7raJ9qIR8PhXu9PCb9WbbWXk1Ig
Message-ID-Hash: GR6BYKPVJVC2L4MAPUCQVU4A25I4LUSP
CC: draft-ietf-httpbis-rfc6265bis.all@ietf.org, ietf-http-wg@w3.org,
 last-call@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bsecdir=5D_Re=3A_Secdir_telechat_review_of_draft-ietf-httpbis-rf?=
	=?utf-8?q?c6265bis-19?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/secdir/8FMyZp6S1x2YlqJRIyonAgsyfsI>

[It seems that Steven responded to my review, but forgot to include =
CC:secdir@ietf.org
and I didn't see the response until Deb has pointed me out to it:
https://mailarchive.ietf.org/arch/msg/httpbisa/BaKETLBU05ID_DOOl87ZCwqTZz=
E/ ]

Hi Steven,

thank you for addressing my concerns. I used the following two links =
from your message to evaluate
changes in the document (I don't know if new I-D is published):

https://github.com/httpwg/http-extensions/commit/4b5c5242984434dcbea15324=
7ec7f7d9a509d0c9
https://github.com/httpwg/http-extensions/commit/f9881b3290e3edf7faeff933=
c8a49b0966285c55

I still have issue with the following sentence (In the Overview section =
of Security Considerations):

"In addition, by default, cookies do not provide confidentiality or =
integrity from network attackers, even when used in conjunction with =
HTTPS."

I think that it should either be elaborated (what "default" do you mean? =
does it mean that cookies are secure for "non-default" and how to reach =
it?=20
"in addition" to what, given that previous text states basically the =
same - weak confidentiality and weak integrity of cookie?) or deleted.

My other concerns are either addressed or explained.

Regards,
Valery.


> -----Original Message-----
> From: Valery Smyslov via Datatracker <noreply@ietf.org>
> Sent: Tuesday, February 11, 2025 4:32 PM
> To: secdir@ietf.org
> Cc: draft-ietf-httpbis-rfc6265bis.all@ietf.org; ietf-http-wg@w3.org; =
last-call@ietf.org
> Subject: [secdir] Secdir telechat review of =
draft-ietf-httpbis-rfc6265bis-19
>=20
> Reviewer: Valery Smyslov
> Review result: Has Nits
>=20
> 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.
>=20
> This document defines the HTTP cookie protocol. The document is well =
written
> and easy to read.
>=20
> 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.
>=20
> I still have some easy to address suggestions that I think would be =
helpful for
> readers.
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> 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.
>=20
> 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"?
>=20
>=20
> _______________________________________________
> secdir mailing list -- secdir@ietf.org
> To unsubscribe send an email to secdir-leave@ietf.org
> wiki: https://wiki.ietf.org/group/secdir/SecDirReview