Re: [websec] draft-ietf-websec-key-pinning

[Tom Ritter <[e-mail]>]

On 26 August 2014 17:10, Chris Palmer <[e-mail]> wrote:
> OK, so, what do you want?
>
> Is it even possible for me to write text you would accept?

Just because I have a concern or preference doesn't mean I don't
really appreciate the work you've done. I do.

I'd like PKP-RO to be cached like PKP and applied the same way, absent
the connection termination (preference). After I realized the
includeSubdomains issue (concern), I want it even more for testing a
deployment than I want it for my prior attack detection arguments
(preference).

I've tried to find all the references someone (e.g. a reviewer) might
want changed to do this.  My suggestions:

----------

The "max-age" directive is REQUIRED to be present within a "Public-
   Key-Pins" header field, and is OPTIONAL within a "Public-Key-Pins-
   Report-Only" header field.

Become

The "max-age" directive is REQUIRED to be present within the "Public-
   Key-Pins" and "Public-Key-Pins-Report-Only" header fields.

----------

Note: There is no purpose to using the PKP-RO header without the
   report-uri directive.  User Agents MAY discard such headers without
   interpreting them further.

Become

Note: The only purpose to using the PKP-RO header without the
   report-uri directive is to include a max-age=0 to clear any previously
   saved PKP-RO directives.  After doing so, User Agents MAY discard
   such headers without interpreting them further.

----------

If a host sets both the PKP header and the PKP-RO header, the UA MUST
   note and enforce Pin Validation as specified by the PKP header, and
   SHOULD process the Pins and directives given in the PKP-RO header.
   If the UA does process the Pins and directives in the PKP-RO header
   it SHOULD evaluate the specified policy and SHOULD report any would-
   be Pin Validation failures that would occur if the report-only policy
   were enforced.

Become

If a host sets both the PKP header and the PKP-RO header, the UA MUST
   note and enforce Pin Validation as specified by the PKP header, and
   SHOULD note and process the Pins and directives given in the PKP-RO header.
   If the UA does process the Pins and directives in the PKP-RO header
   it SHOULD evaluate the specified policy and SHOULD report any would-
   be Pin Validation failures that would occur if the report-only policy
   were enforced.

----------

Upon receipt of the PKP response header field, the UA notes the host
   as a Known Pinned Host, storing the Pins and their associated
   directives in non-volatile storage (for example, along with the HSTS
   metadata).  The Pins and their associated directives are collectively
   known as Pinning Metadata.

Become

Upon receipt of a PKP or PKP-RO response header field, the UA notes the host
   as a Known Pinned Host, storing the Pins and their associated
   directives in non-volatile storage (for example, along with the HSTS
   metadata).  The Pins and their associated directives are collectively
   known as Pinning Metadata.

----------

It received the PKP response header field over an error-free TLS
      connection.

Become

It received the PKP or PKP-RO response header field over an error-free TLS
      connection.

----------

If the PKP response header field does not meet all three of these
   criteria, the UA MUST NOT note the host as a Pinned Host.  A PKP
   response header field that meets all these critera is known as a
   Valid Pinning Header.

Become

If the PKP or PKP-RO response header field does not meet all three of these
   criteria, the UA MUST NOT note the host as a Pinned Host.  A response
   header field that meets all these critera is known as a Valid Pinning Header.

----------

The UA need not note any Pins or other policy expressed in the PKP-RO
   response header field, except for the purpose of determining that it
   has already sent a report for a given policy.  UAs SHOULD make a best
   effort not to inundate report-uris with redundant reports.

be removed entirely. The final sentence is included previously as a
SHOULD at the end of 2.1.3

----------
In Section 2.6:

Otherwise, the UA MUST
   treat this Pin Validation Failure as a non-recoverable error.

Become

Otherwise, if the Pinning Metadata indicates the policy was not set by
   the PKP-RO header, the UA MUST treat this Pin Validation Failure
   as a non-recoverable error.

----------


I believe that Section 2.3.2, paragraph "If a host sets the PKP-RO
header..." is clear enough as is.

-tom