Subject: [websec] Question regarding RFC 6797

From: Claudio Saavedra <[email-masked]>
Date: Mon, 28 May 2018 11:20:02 +0300

Hi,

I am currently implementing HSTS support for libsoup and there is one
point that I find confusing and I would appreciate your comments. 

Section 8.1 states:

   Update the UA's cached information for the Known HSTS Host if either
   or both of the max-age and includeSubDomains header field value
   tokens are conveying information different than that already
   maintained by the UA.

The way I understand this is that if a HSTS host keeps sending the same
values to a conforming client, this should not update the information
cached and hence the cached information will expire after max-age
seconds have passed since the _first_reception_ of this header.

However, section 11.2 states:

   The "constant value into the future" approach can be accomplished by
   constantly sending the same max-age value to UAs.

   For example, a max-age value of 7776000 seconds is 90 days:

   Strict-Transport-Security: max-age=7776000

   Note that each receipt of this header by a UA will require the UA to
   update its notion of when it must delete its knowledge of this Known
   HSTS Host.

This seems to contradict what I quoted from section 8.1. If the server
constantly sends a max-age of 7776000 and includeSubDomains is not
changed (which is implicit in the example), then by 8.1 the cache
information won't be updated.

Would you mind clarifying this?

Best regards,

Claudio

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 28 May 2018 13:21:02 +0200

> seconds have passed since the _first_reception_ of this header.

I have a hard time reading it another way as well; if true, this would
be a security bug.

-- 
https://annevankesteren.nl/

---

From: Claudio Saavedra <[email-masked]>
Date: Tue, 29 May 2018 12:20:28 +0300

On Mon, 2018-05-28 at 13:21 +0200, Anne van Kesteren wrote:
> I have a hard time reading it another way as well; if true, this
> would be a security bug.

So if this is a security bug, I'm understanding that the desired
behavior would be the one described in 11.2. What can be done in the
specification to deal with this? Can it be reworded/updated? How can we
implementors know which of the behaviors described in 8.1 or 11.2 is to
be honored?

Best regards,

Claudio

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 29 May 2018 11:30:21 +0200

> implementors know which of the behaviors described in 8.1 or 11.2 is to

I'm not sure. Raising errata would be good, but it's always a little
bit unclear to me whether it's going to be accepted, but at least
there's a way to find the issue then (other than browsing the mailing
list), even if not accepted. After that it's probably updating the
document, which is rather involved.

---

From: Claudio Saavedra <[email-masked]>
Date: Tue, 29 May 2018 12:33:36 +0300

> document, which is rather involved.

Thanks, I'll raise an errata then and follow 11.2 in the implementation
for now.

Claudio

---

From: Claudio Saavedra <[email-masked]>
Date: Tue, 29 May 2018 12:51:04 +0300

On Tue, 2018-05-29 at 12:33 +0300, Claudio Saavedra wrote:
> > On Tue, May 29, 2018 at 11:20 AM, Claudio Saavedra <csaavedra@igali
> > a.
> > com> wrote:
> Thanks, I'll raise an errata then and follow 11.2 in the
> implementation for now.

Errata for this in https://www.rfc-editor.org/errata/eid5372 

Claudio

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 29 May 2018 12:03:59 +0200

> Errata for this in https://www.rfc-editor.org/errata/eid5372

Thank you!