HTTP Strict Transport Security (HSTS)
RFC 6797

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    websec mailing list <websec@ietf.org>,
    websec chair <websec-chairs@tools.ietf.org>
Subject: Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)

The IESG has approved the following document:
- 'HTTP Strict Transport Security (HSTS)'
  (draft-ietf-websec-strict-transport-sec-14.txt) as Proposed Standard

This document is the product of the Web Security Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/


Technical Summary

The specification defines a mechanism enabling web sites to declare
themselves accessible only via secure connections, and/or for users
to be able to direct their user agent(s) to interact with given sites
only over secure connections.  This overall policy is referred to as
HTTP Strict Transport Security (HSTS).  The policy is declared by web
sites via the Strict-Transport-Security HTTP response header field,
and/or by other means, such as user agent configuration, for example.

Working Group Summary

There was a good discussion in the WG on HSTS over an extended period of time.
Most of the draft consensus appears to be pretty strong. Discussion activity in the
last 4 weeks during WGLC has been relatively low, though no hot controversies did
show up.

There is one last-minute item raised in Paris that was less discussed than could have
been: whether the HSTS header should have a "report-only" feature. There was some
minor discussion and so far it appears that rough consensus is for the draft as it is
(without adding that feature), but the number of votes for this feature was not very high.

The GenART review during Last Call noted that text at the end of Section 6.1 specifies
and extension point and says that a registry might be created by the first extension
that needs it.  The review suggested either creating the registry now or, alternatively,
specifying its registration policy now to prevent an inappropriate choice of policy
later.  The working group decided to do the latter, and chose IETF Review for the
policy.

Document Quality

The document is in good shape.
The ABNF was reviewed and verified by several experts and appears to be correct.
The header is already deployed and implemented by several websites and browser
implementations.

Personnel

Shepherd: Tobias Gondrom
AD: Barry Leiba