Subject: Re: [websec] IETF WebSec WG <[email-masked]>

From: =JeffH <[email-masked]>
Date: Wed, 02 May 2012 11:56:03 -0700

Hi Alexey, thanks for the review, apologies for latency.

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

Does the last bullet item above not address those questions?

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

We can place in the above para whatever we/you/ourADs wish. Suggestions welcome.

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

the above is being discussed in the "Showing errors in HSTS" thread.

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

It's referenced way up at beginning of spec, but now ref'd here also in my -07 
working copy.

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

As far as I can tell, having had fairly extensive discussions with IDNA folk 
both privately and on various lists such as idna-update@, the above relects the 
the unfortunate state of the world at this time. For instance, Pete Resnick 
signed off on the language in the spec in this message to websec@...

Re: [websec] wrt IDN processing-related security considerations for 
draft-ietf-websec-strict-transport-sec
https://www.ietf.org/mail-archive/web/websec/current/msg01015.html

we should probably fork off any further discussion on this topic to that thread.

 > Also, does "in order to facilitate their IDNA transition" apply
 > to the second reference or to both references?

It applies to both. One may implement [RFC5895] /or/ [UTS46] to facilitate 
one's IDNA transition (as I understand it).

again, followups on this item and the above should probably be in the "Re: 
[websec] wrt IDN processing-related security considerations for 
draft-ietf-websec-strict-transport-sec" thread here on websec@.

 > In Section 14.5: NTP needs an Informative Reference.

fixed in my -07 working copy.

 > 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

fixed in my -07 working copy

thanks again,

=JeffH