Hi,
Below is my WGLC review of the draft:
6.1. Strict-Transport-Security HTTP Response Header Field
The Strict-Transport-Security HTTP response header field (STS header
field) indicates to a UA that it MUST enforce the HSTS Policy in
regards to the host emitting the response message containing this
header field.
The ABNF syntax for the STS header field is:
Strict-Transport-Security = "Strict-Transport-Security" ":"
*( ";" [ directive ] )
As already noted by other reviewers, this effectively requires a leading ";"
which is not what was intended here.
The two directives defined in this specification are described below.
The overall requirements for directives are:
o The order of appearance of directives is not significant.
o All directives MUST appear only once in an STS header field.
o Directive names are case-insensitive.
o UAs MUST ignore any STS header fields containing directives that
do not conform to their ABNF definition.
Should this list also say something about how unrecognized directives
should be treated? I.e. are they ignored by default, is the whole
STS header field ignored, etc.
Additional directives extending the semantic functionality of the STS
header field may be defined in other specifications (which "update"
this specification),
Is this a requirement on future extensions?
(In general "updating" this specification using Updates: in the header
of the relevant RFC
is a) a heavy weight mechanism (it prevents Experimental extensions) and
b) this seems
like a wrong mechanism anyway, as Updates usually means that the
document being
updated can't be implemented without the document which updates it.)
using the STS directive extension point.
8.3. Errors in Secure Transport Establishment
When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 11 "User Agent Implementation Advice",
below) if there are any errors (e.g., certificate errors), whether
"warning" or "fatal" or any other error level, with the underlying
secure transport. This includes any issues with certificate
revocation checking whether via the Certificate Revocation List (CRL)
[RFC5280], or via the Online Certificate Status Protocol (OCSP)
[RFC2560].
This was discussed in Paris, but I had this in my notes already and would
like to emphasize this: I assume that explaining the reason for the failure
to the user (without letting the user to opt-out) is Ok? I think the
document
needs to make it clear that this is not prohibited.
10.3. Implications of includeSubDomains
For example, certification authorities often offer their CRL
distribution and OCSP services over plain HTTP, and sometimes at a
The first use of OCSP needs an Informative reference.
subdomain of a publicly-available web application which may be
secured by TLS/SSL. For example, <https://example-ca.com/> is a
publicly-available web application for "Example CA", a certification
authority. Customers use this web application to register their
public keys and obtain certificates. Example CA generates
certificates for customers containing
<http://crl-and-ocsp.example-ca.com/> as the value for the "CRL
Distribution Points" and "Authority Information Access:OCSP"
certificate fields.
13. Internationalized Domain Names for Applications (IDNA): Dependency
and Migration
IDNA2008 obsoletes IDNA2003, but there are differences between the
two specifications, and thus there can be differences in processing
(e.g., converting) domain name labels that have been registered under
one from those registered under the other. There will be a
transition period of some time during which IDNA2003-based domain
name labels will exist in the wild. User agents SHOULD implement
IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of
[RFC5894]) or [UTS46] in order to facilitate their IDNA transition.
I might be kicking a dead horse here, but MAY sounds a bit weak.
I especially dislike having the choice between 2 incompatible specs,
I think this might cause some interop problems.
Also, does "in order to facilitate their IDNA transition" apply
to the second reference or to both references?
If a user agent does not implement IDNA2008, the user agent MUST
implement IDNA2003.
In Section 14.5: NTP needs an Informative Reference.
15. IANA Considerations
Below is the Internet Assigned Numbers Authority (IANA) Provisional
I think here (and below) we should use "Permanent" registration for this
header field.
Message Header Field registration information per [RFC3864].
Header field name: Strict-Transport-Security
Applicable protocol: HTTP
Status: provisional
Author/Change controller: TBD
Specification document(s): this one
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
