MIME-Version: 1.0
References: 
 <173928072730.554181.11643604175051228621@dt-datatracker-75c44cbbdf-pxnd6>
 <0b1901dc2890$d0e2abf0$72a803d0$@smyslov.net>
 <CAKvzGWeU=c8w1-gOzNsKPdgNvxHXNgEa86Yubep=b54LbMUzBg@mail.gmail.com>
 <123901dc2eaf$a0ed8f30$e2c8ad90$@smyslov.net>
In-Reply-To: <123901dc2eaf$a0ed8f30$e2c8ad90$@smyslov.net>
From: Steven Bingler <bingler@chromium.org>
Date: Fri, 26 Sep 2025 14:33:35 -0400
Message-ID: 
 <CAKvzGWeBW7jK34KsZV8Mk48QmWmjmxWibk_LkCkEZ=5rLX4B6g@mail.gmail.com>
To: Valery Smyslov <valery@smyslov.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2VQ32OSJCVYIIOVM6T67ZK7IRHLFUKQJ
CC: secdir@ietf.org, 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/9SiCsvqbPC3OM4D_YDBQbupX9zg>

Valery,

> If this is not a requirement (in RFC 2119 sense) then I suggest
> to change it to "has to" or "needs" so that no such questions arise.

Sounds good, I've changed "must" to "needs to".

- Steven

On Fri, Sep 26, 2025 at 2:34=E2=80=AFAM Valery Smyslov <valery@smyslov.net>=
 wrote:
>
> Hi Steven,
>
> > Hi Valery,
> >
> > > It seems that Steven responded to my review, but forgot to include CC=
:secdir@ietf.org
> >
> > Yes, my mistake.
> >
> > > I still have issue with the following sentence (In the Overview secti=
on of Security Considerations):
> >
> > I'd prefer to keep this text because it sets up the later sections
> > which go into greater detail.
> >
> > I have a PR with my proposed change, please take a look and let me
> > know if it resolves your concern:
> > https://github.com/httpwg/http-extensions/pull/3256
>
> This explanation is helpful, thank you.
> I just wonder whether "must" should be "MUST" in the sentence:
>
>     This means that
>     a cookie must explicitly specify any protective attributes.
>
> If this is not a requirement (in RFC 2119 sense) then I suggest
> to change it to "has to" or "needs" so that no such questions arise.
>
> Regards,
> Valery.
>
> > - Steven
> >
> > On Fri, Sep 19, 2025 at 11:21=E2=80=AFAM Valery Smyslov <valery@smyslov=
.net> wrote:
> > >
> > > [It seems that Steven responded to my review, but forgot to include C=
C: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_DOOl87ZCw=
qTZzE/ ]
> > >
> > > 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/4b5c5242984434dcbea1=
53247ec7f7d9a509d0c9
> > > https://github.com/httpwg/http-extensions/commit/f9881b3290e3edf7faef=
f933c8a49b0966285c55
> > >
> > > I still have issue with the following sentence (In the Overview secti=
on of Security Considerations):
> > >
> > > "In addition, by default, cookies do not provide confidentiality or i=
ntegrity from network attackers, even when
> > used in conjunction with HTTPS."
> > >
> > > I think that it should either be elaborated (what "default" do you me=
an? does it mean that cookies are secure for
> > "non-default" and how to reach it?
> > > "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-rfc6=
265bis-19
> > > >
> > > > 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.  T=
hese
> > > > comments were written primarily for the benefit of the security are=
a directors.
> > > > Document editors and WG chairs should treat these comments just lik=
e any other
> > > > last call comments.
> > > >
> > > > This document defines the HTTP cookie protocol. The document is wel=
l written
> > > > and easy to read.
> > > >
> > > > The Security Considerations section is mostly taken intact from RFC=
 6265
> > > > (except that considerations for newly introduced SameSite cookies a=
re added),
> > > > and only overviews "a few of the more salient issues". This is a bi=
t
> > > > disappointing, I would have expected that more considerations are a=
dded based
> > > > on 14 years experience since RFC 6265 was published. However, I und=
erstand that
> > > > the list of security considerations would have been very long and s=
till hardly
> > > > complete. Since it seems to be next to impossible to accurately lis=
t all the
> > > > possible cookie exploits, I wil mark the document as "Ready", but w=
ith a
> > > > reservation, that the the Security Considerations section is intent=
ionally 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 u=
se, that the
> > > > server imposes via attributes, are not guaranteed to be honored eve=
n 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 cook=
ie beyond
> > > > its lifetime. Thus, the imposed restrictions for the received cooki=
es MUST be
> > > > checked by the server.
> > > >
> > > > 2. Section 8.1 states that "by default, cookies do not provide conf=
identiality
> > > > or integrity from network attackers, even when used in conjunction =
with HTTPS".
> > > > In my reading this sounds like HTTPS is useless for cookies securit=
y. I think
> > > > that this needs a clarification. While use of HTTPS cannot prevent =
network
> > > > attacks using cookies mounted by other participants in HHTP communi=
cations
> > > > (like cross-site attacks), it does prevent eavesdropping and manipu=
lation of
> > > > cookies by on-path entities that don't participate in these communi=
cations. I
> > > > believe it should be emphisized that encrypted transport does reduc=
e 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 tr=
ansmission,
> > > > with unpredictable results". I failed to understand how this is con=
cerned 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 compatib=
ility
> > > > constraints permit". This gives no concrete recommendations, and no=
 examples,
> > > > thus making this requirement vague and subjective. I think this req=
uirement
> > > > should be provided with more details how to deal with it.
> > > >
> > > > Just out of curiosity - the draft adds a requirement that cookie SH=
OULD NOT be
> > > > greater than 400 days. I wonder why this particular margin was chos=
en. Why not
> > > > 365 days (a year) - it looks like a natural equivalet to "very long=
, but not
> > > > infinite"?
> > > >
> > > >
> > > > _______________________________________________
> > > > secdir mailing list -- secdir@ietf.org
> > > > To unsubscribe send an email to secdir-leave@ietf.org
> > > > wiki: https://wiki.ietf.org/group/secdir/SecDirReview
> > >
> > >
> > >
> > >
>