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

From: =JeffH <[email-masked]>
Date: Wed, 02 May 2012 12:45:53 -0700

[ resent with correct Subject: ]

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 May 2012 13:40:43 -0600

On 5/2/12 1:45 PM, =JeffH wrote:

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

Unfortunately, I think the text that Jeff produced is about the best
we're going to do right now.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 4 May 2012 09:47:09 +0100

On 3 May 2012, at 20:40, Peter Saint-Andre <[email-masked]> wrote:

> we're going to do 

We are setting ourselves up for some interop problems. We should bite the bullet and through RFC 5894 or UTS 46 out.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 04 May 2012 12:10:56 +0100

> Hi Alexey, thanks for the review, apologies for latency.
Hi Jeff,
> Does the last bullet item above not address those questions?
No. The last bullet is talking about recognized, but invalid data. I am 
asking about unrecognized data.

> We can place in the above para whatever we/you/ourADs wish. 
It is not about the location of this sentence. I think you need to 
strike "(which "update" this specification)".

> 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@...
Commented on this in reply to Peter.
> It applies to both. One may implement [RFC5895] /or/ [UTS46] to 
> facilitate one's IDNA transition (as I understand it).
Can you please move "in order to facilitate their IDNA transition" to 
the beginning of the sentence? I think this will make it clearer.
>
> again, followups on this item and the above should probably be in the 
> "Re: [websec] wrt IDN processing-related security considerations for

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 May 2012 11:00:22 -0600

> We are setting ourselves up for some interop problems. We should bite the bullet and through RFC 5894 or UTS 46 out.

Jeff's point is that we already have interop problems but we need to be
realistic about the state of the browsers. From reports we've received,
some of them will be stuck on IDNA2003 for a long time...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/