On 5 April 2014 14:37, Trevor Perrin <[email protected]> wrote: > I think your intent is that there's 2 different types of pins (regular > and report-only), which don't interact. I.e. setting max-age=0 on a > regular PKP header doesn't clear PKP-RO pins, and vice versa. And > when contacting a pinned site, the UA might have to apply both pins to > it. > > Seems reasonable, if other people agree.
That is my take on it as well, and what I desired. I think the wording needs to be clarified significantly however. All of the logic around the interaction of PKP and PKPRO is buried in the report-uri subsection. I would suggest a new 2.3.2 and change the report-uri section. Textual Suggestions: My thoughts on the report-uri section: <section anchor="report-uri" title="The report-uri Directive"> <t>The OPTIONAL "report-uri" directive indicates the URI to which the UA SHOULD report Pin Validation failures (<xref target="validating-pinned-connections"/>). The UA POSTs the reports to the given URI as described in <xref target="reporting-pin-validation-failure"/>.</t> <t>When used in the Public-Key-Pins or Public-Key-Pins-Report-Only header, the presence of a report-uri directive indicates to the UA that in the event of Pin Validation failure it SHOULD POST a report to the report-uri. If the header is Public-Key-Pins, the UA should do this in addition to terminating the connection (as described in <xref target="validating-pinned-connections"/>).</t> <t>Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If the scheme in the report-uri is HTTPS, UAs MUST perform Pinning Validation when the host in the report-uri is a Known Pinned Host; similarly, UAs MUST apply HSTS if the host in the report-uri is a Known HSTS Host.</t> <t>Note that the report-uri need not necessarily be in the same Internet domain or web origin as the Known Pinned Host.</t> <t>UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. For example, if connecting the report-uri itself incurs a Pinning Validation failure or other certificate validation failure, the UA MUST cancel the connection (and MAY attempt to re-send the report later). Similarly, if Known Pinned Host A sets a report-uri referring to Known Pinned Host B, and if B sets a report-uri referring to A, and if both hosts fail Pin Validation, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts.</t> <t>UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same report-uri more than once.</t> <!-- I disagree or misunderstand with this, will send a separate email: <t>UAs MUST NOT send a report if the Host is not already a Known Pinned Host. (I.e., the UA's first connection to a Host fails Pin Validation.) The reason for this is so that a potential active network attacker cannot learn about a UA's certificate validation and Pin Validation procedures and state.</t> --> </section><!-- report-uri --> New 2.3.2 Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-Only headers simultaneously. The headers do not interact with one another but the UA MUST process the Public-Key-Pins header and SHOULD process both. The Public-Key-Pins header is processed as according to section 2.3.1. When the Public-Key-Pins-Report-Only header is used with a report-uri, the UA SHOULD POST reports for Pin Validation failures to the indicated report-uri, although the UA MUST NOT enforce Pin Validation. That is, in the event of Pin Validation failure when the host has set the Public-Key-Pins-Report-Only header, the UA performs Pin Validation only to check whether or not it should POST a report, but not for causing connection failure.</t> Note: There is no purpose to using the Public-Key-Pins-Report-Only header without the report-uri directive. User Agents MAY discard such headers without interpretting them further. <t>If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header as specified by the max-age directive. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only 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.</t> <t>If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin Validation as specified by the Public-Key-Pins header, and SHOULD note the Pins and directives given in the Public-Key-Pins-Report-Only header. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only 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.</t> _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
