[secdir] Re: Secdir telechat review of draft-ietf-httpbis-rfc6265bis-19

[Valery Smyslov <[e-mail]>]

Hi Steven,

> Hi Valery,
> 
> > It seems that Steven responded to my review, but forgot to include CC:[e-mail]
> 
> Yes, my mistake.
> 
> > I still have issue with the following sentence (In the Overview section 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 AM Valery Smyslov <[e-mail]> wrote:
> >
> > [It seems that Steven responded to my review, but forgot to include CC:[e-mail]
> > and I didn't see the response until Deb has pointed me out to it:
> > https://mailarchive.ietf.org/arch/msg/httpbisa/BaKETLBU05ID_DOOl87ZCwqTZzE/ ]
> >
> > 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/4b5c5242984434dcbea153247ec7f7d9a509d0c9
> > https://github.com/httpwg/http-extensions/commit/f9881b3290e3edf7faeff933c8a49b0966285c55
> >
> > 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?
> > "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 <[e-mail]>
> > > Sent: Tuesday, February 11, 2025 4:32 PM
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail]
> > > Subject: [secdir] Secdir telechat review of draft-ietf-httpbis-rfc6265bis-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.  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"?
> > >
> > >
> > > _______________________________________________
> > > secdir mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > wiki: https://wiki.ietf.org/group/secdir/SecDirReview
> >
> >
> >
> >