[websec] Review of draft-ietf-websec-strict-transport-sec-06.txt

[Alexey Melnikov <[e-mail]>]

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