HTTP Strict Transport Security (HSTS)
draft-ietf-websec-strict-transport-sec-14

[Ballot comment]
6.1:

  Additional directives extending the semantic functionality of the STS
  header field can be defined in other specifications, with a registry
  (having an IANA policy definition of IETF Review [RFC5226]) defined
  for them at such time.

Is IETF Review really necessary? Seems to me "Specification Required" is more than sufficient, and I would not be completely averse to "First Come First Served".

15: Why not set up the directives registry now?

[Ballot comment]
I was going to say "Well written indeed" and leave it at that but I thought s14 was outstanding.

In s11.2: Maybe make this a SHOULD:

Additionally, server implementers should consider employing a default
max-age value of zero in their deployment configuration systems.

or say:

Additionally, it is RECOMMENDED that server implementers employ
a default max-age value of zero in their deployment configuration
systems.

[Ballot comment]

This is a very well written document. Thanks!

Only comment I have is that 6.1 says that directives are
optional or required according to their definitions. Is it actually
possible to define a new required directive without breaking
interop with this spec? If not then I think saying that would
be good.

[Ballot discuss]
I have two points that to discuss that I think will be easy to address.

1) Consider the case where a policy maker or example.edu configures the server
to enforce STS, and to include the "includeSubDomains" directive in the STS
header field that server returns. This policy maker may think they've set policy
for all the servers inside example.edu at this point, which is clearly not the case.
A browser that only accessed a departmental server, say math.example.edu, would
never see (so would never cache from) the response that contains the policy.
Was this case discussed in the WG? Could some text be added to the document
to make it more likely that the server administrator for example.edu would
understand that configuring just the top level server will only cause browsers
that actually access that top-level server to use STS on subdomains?

2) The document does a great job of discussing how to handle the expiration time
on cached entries when setting or updating those entries (that is, when processing
a response). I'm not finding any text that says an implementation should check the
expiration time before _using_ a cache entry (preparing a new request). I expected
to see something in 8.3 (or perhaps 8.2) calling out that expired cache entries
must not be used.

[Ballot comment]
In section 14.4's first bullet, where you note "the web application will be
rendered unusable for the UA's user", consider calling out this as a reason
for clients to consider providing a way for users to remove entries from the cache.

Nit: In section 7.1 second paragraph "may be accomplished over the HTTP protocol"
could be read to mean over an unsecure transport.

IANA has reviewed draft-ietf-websec-strict-transport-sec-11 and has the following comments:

IANA has a question about the IANA Action requested in this document.

Upon approval of this document, IANA understands that there is a single
IANA action which must be completed.

In the Permanent Message Header registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

a new message header will be registered as follows:

Header field name: Strict-Transport-Security
Applicable protocol: HTTP
Status: standard
Specification document(s): this one

Currently the Permanent Message Header registry is maintained through
expert review as defined in RFC 5226.

IANA Question -> has the document been reviewed by the Permanent Message
Header registry expert?

IANA understands that the action above is the only action required to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (HTTP Strict Transport Security (HSTS)) to Proposed Standard


The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'HTTP Strict Transport Security (HSTS)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This 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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/

This Proposed Standard has downrefs to the following Informational RFCs:
  RFC 2818, HTTP Over TLS
  RFC 5895, Mapping Characters for IDNA
...and a normative reference to the following obsolete RFC, which is cited alongside its replacement:
  RFC 3490, Internationalizing Domain Names in Applications

No IPR declarations have been submitted directly on this I-D.