[websec] draft-ietf-websec-key-pinning-20 references
Hi there. Below some nits wrt references [RFC4627] Crockford, D., The application/json Media Type for JavaScript Object Notation (JSON), RFC 4627, July 2006. Obsoleted by http://tools.ietf.org/html/rfc7159. [RFC4634] Eastlake, D. and T. Hansen, US Secure Hash Algorithms (SHA and HMAC-SHA), RFC 4634, July 2006. Obsoleted by http://tools.ietf.org/html/rfc6234. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, Transport Layer Security (TLS) Extensions, RFC 3546, June 2003. ...also obsoleted, in this case apparently by a set of specs. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] draft-ietf-websec-key-pinning-20 feedback
Hi there. Some more quick feedback, somewhat unstructured... Throughout: please say header field rather than header. The Public-Key-Pins and Public-Key-Pins-Report-Only header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are new response headers defined in this specification. They are used by a server to indicate that a s/server/origin server/ maybe? Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header fields, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The field values of both header fields conform to the same rules. Public-Key-Directives = [ directive ] *( OWS ; OWS [ directive ] ) directive = simple-directive / pin-directive simple-directive = directive-name [ = directive-value ] directive-name= token directive-value = token / quoted-string pin-directive = pin- token = quoted-string 1) I would recommend not to special-case pin-directive here, as it makes the ABNF ambiguous. Just put the additional requirements into prose. 2) The value of pin-directive ought to allow token syntax as well. (Otherwise a conforming parser will need to special-case their parsing which doesn't make any sense at all). given header field. Directives are either optional or required, as stipulated in their definitions. OPTIONAL or REQUIRED, I assume? Additional directives extending the semantic functionality of the header fields can be defined in other specifications. The first such specification will need to define a reistry for such directives. registry. According to rule 5, above, the UA MUST ignore pin-directives with Repeats a requirement. Maybe do not use MUST here; instead say will. tokens naming hash algorithms it does not recognize. If the set of remaining effective pin-directives is empty, and if the host is a Known Pinned Host, the UA MUST cease to consider the host as a Known Pinned Host (the UA should fail open). The UA should indicate to SHOULD? UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. MAY? (in general: try to avoid lowercase RFC2119 terms) Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] draft-ietf-websec-key-pinning-20 feedback
Hi there. Some more quick feedback, somewhat unstructured... Throughout: please say header field rather than header. The Public-Key-Pins and Public-Key-Pins-Report-Only header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are new response headers defined in this specification. They are used by a server to indicate that a s/server/origin server/ maybe? Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header fields, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The field values of both header fields conform to the same rules. Public-Key-Directives = [ directive ] *( OWS ; OWS [ directive ] ) directive = simple-directive / pin-directive simple-directive = directive-name [ = directive-value ] directive-name= token directive-value = token / quoted-string pin-directive = pin- token = quoted-string 1) I would recommend not to special-case pin-directive here, as it makes the ABNF ambiguous. Just put the additional requirements into prose. 2) The value of pin-directive ought to allow token syntax as well. (Otherwise a conforming parser will need to special-case their parsing which doesn't make any sense at all). given header field. Directives are either optional or required, as stipulated in their definitions. OPTIONAL or REQUIRED, I assume? Additional directives extending the semantic functionality of the header fields can be defined in other specifications. The first such specification will need to define a reistry for such directives. registry. According to rule 5, above, the UA MUST ignore pin-directives with Repeats a requirement. Maybe do not use MUST here; instead say will. tokens naming hash algorithms it does not recognize. If the set of remaining effective pin-directives is empty, and if the host is a Known Pinned Host, the UA MUST cease to consider the host as a Known Pinned Host (the UA should fail open). The UA should indicate to SHOULD? UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. MAY? (in general: try to avoid lowercase RFC2119 terms) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Mon, Aug 25, 2014 at 7:05 PM, Tom Ritter t...@ritter.vg wrote: No, PKP-RO is not meant to be cached. In this respect, it behaves similar to Content-Security-Policy's reporting mechanism. Ah, interesting. I'm curious why not? Is there no use-case for allowing report-only pins to be persisted? I think there definitely are, and I and most organizations I advise would like that option. What would they get from it that they would not get from just consistently serving the PKP-RO header? ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
primarily a debugging aid for The Alice Foundation and BobCorp to get PKP working. (What all Trents do we need to trust, anyway?) As a site operator, I'd think of PKP-RO as a debugging aid more along the lines of: If I turn this thing on, will anything break for anyone? If PKP-RO doesn't have the same semantics as PKP, its utility for answering that question declines. -Eric -Original Message- From: Chris Palmer Sent: Tuesday, August 26, 2014 3:51 PM To: Tom Ritter Cc: Eric Lawrence ; draft-ietf-websec-key-pinn...@tools.ietf.org ; IETF WebSec WG ; Ryan Sleevi Subject: Re: [websec] draft-ietf-websec-key-pinning On Tue, Aug 26, 2014 at 1:33 PM, Tom Ritter t...@ritter.vg wrote: Well the whole threat model of HPKP (without preloading) is an attacker that can MITM some TLS connections, but not all of them, right? By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The threat model is that The Alice Foundation wants to trust only Trents 1, 4, and 9, and no other Trents, to vouch for her identity. That way, if Trent 6 mis-issues for The Alice Foundation, Mallory cannot make use of the mis-issued certificate in an attack. But, yes, Mallory can still attack CarolCorp, if CarolCorp does not use pinning or pins to Trent 6. Requiring PKP-RO to be on every load would allow an attacker to strip the header on the connections they MITM. Only if The Alice Foundation did not also use a regular PKP header. Letting it be cached allows an organization to put a max-age of 45 days on it, without the risk of bricking their site if they aren't administratively competent. Obviously an attacker can also block the reports from being sent, but I'm hoping that the clause In any case of report failure, the UA MAY attempt to re-send the report later will be considered in this case, and that UAs will make an attempt at getting potentially blocked reports out at a later date. Yeah, sort of. But don't think of PKP-RO as a defense against attacks, even if it might sometimes have that secondary benefit. It is primarily a debugging aid for The Alice Foundation and BobCorp to get PKP working. (What all Trents do we need to trust, anyway?) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On 26 August 2014 15:51, Chris Palmer pal...@google.com wrote: Requiring PKP-RO to be on every load would allow an attacker to strip the header on the connections they MITM. Only if The Alice Foundation did not also use a regular PKP header. Correct. Letting it be cached allows an organization to put a max-age of 45 days on it, without the risk of bricking their site if they aren't administratively competent. Obviously an attacker can also block the reports from being sent, but I'm hoping that the clause In any case of report failure, the UA MAY attempt to re-send the report later will be considered in this case, and that UAs will make an attempt at getting potentially blocked reports out at a later date. Yeah, sort of. But don't think of PKP-RO as a defense against attacks, even if it might sometimes have that secondary benefit. It is primarily a debugging aid for The Alice Foundation and BobCorp to get PKP working. (What all Trents do we need to trust, anyway?) I'm not going to put words in your mouth, because different authors have different opinions about things, but I will quote from another: Ryan Sleevi wrote (http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0001.html) I wrote: 1. A large site that is commonly proxies by corporate and malicious actors wishes to monitor how common this is done. They place javascript bindings in their code to view the user's certificate and report the observed value. Note this use case has already been performed by Facebook, who had to resort to Flash to do so, because javascript did not provide the functionality. Use report-uri with HPKP, in report-only mode I don't consider PKP-RO as a defense, but as an attempt at detection of attacks, with no risk of breaking your site. It is extraordinarily useful to be notified of attacks against your users, even if they are not prevented. They help you understand where you should invest time and money. The foot-gun potential is very high with HPKP, we all know that. It's high enough to the point that many organizations, who have someone maintaining a website part time (or outsource it) may forgoe PKP entirely because it makes them nervous - but they would be happy to deploy a no-risk PKP-RO. But the benefit of doing so if it is not being cached is extraordinarily low, to the point it's probably not worth doing. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Tue, Aug 26, 2014 at 2:06 PM, Tom Ritter t...@ritter.vg wrote: The foot-gun potential is very high with HPKP, we all know that. It's high enough to the point that many organizations, who have someone maintaining a website part time (or outsource it) may forgoe PKP entirely because it makes them nervous - but they would be happy to deploy a no-risk PKP-RO. But the benefit of doing so if it is not being cached is extraordinarily low, to the point it's probably not worth doing. 3 full years ago, HPKP was conceived as a single new directive to piggyback on HSTS. Now it's a design-by-committee extravaganza with knobs and bells and whistles all over the place. It also has a jaunty cap. The cap is not a protective helmet, but hey — it *is* jaunty as all get-out. :) I just want to get something published, even if it's imperfect, so we can move on. This process is taking my time away from other important tasks, and I can't let that happen much longer. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Tue, Aug 26, 2014 at 2:04 PM, Chris Palmer pal...@google.com wrote: On Tue, Aug 26, 2014 at 1:58 PM, Eric Lawrence ericlaw1...@hotmail.com wrote: As a site operator, I'd think of PKP-RO as a debugging aid more along the lines of: If I turn this thing on, will anything break for anyone? If PKP-RO doesn't have the same semantics as PKP, its utility for answering that question declines. PKP-RO has the same semantics as PKP, at the time of Pin Validation, which is what matters. That's not completely true, because PKP affects Pin Validation of other connections, and PKP-RO doesn't. So turning on PKP-RO tests do browsers construct the certificate path I expect. It doesn't test does my site return the correct certificate for all connections. So Eric's point is valid: PKP-RO doesn't provide an administrator much confidence that their site is ready for PKP, and might even mislead them. Trevor ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On 26 August 2014 16:38, Trevor Perrin tr...@trevp.net wrote: That's not completely true, because PKP affects Pin Validation of other connections, and PKP-RO doesn't. ... So Eric's point is valid: PKP-RO doesn't provide an administrator much confidence that their site is ready for PKP, and might even mislead them. This is especially true if includeSubdomains is enabled. It'd be common for that directive to apply to hosts that the -RO header would not be included on. In PKP-RO, it would not be applied to them; in PKP it would. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Tue, Aug 26, 2014 at 6:10 PM, Chris Palmer pal...@google.com wrote: On Tue, Aug 26, 2014 at 2:42 PM, Tom Ritter t...@ritter.vg wrote: This is especially true if includeSubdomains is enabled. It'd be common for that directive to apply to hosts that the -RO header would not be included on. In PKP-RO, it would not be applied to them; in PKP it would. OK, so, what do you want? Is it even possible for me to write text you would accept? The answer may be no here which would suggest dropping PKP-RO completely as an alternative way forward. Taking a step back, this thread features two sides arguing that this feature is (largely) useless for what the other side wants it for (testing vs. security). As pointed out, the current version is not nearly sufficient for testing a site's PKP-readiness due to subdomains and (potentially) load-balancing a domain onto servers with different keys (some of which may not be in the pin set and not set PKP-RO and be missed by setting the header on other servers). Testing with -RO is surely better than no testing at all, but it seems most domains would need to do more extensive testing manually by crawling/viewing network traffic/etc. at which point they'd gain the benefit of -RO testing anyways. Maybe there is some benefit for quick tests to see what certs UAs are actually receiving, which it was pointed out Facebook used Flash to achieve (I know of at least two other academic research efforts that have used the same approach). But if this is the goal, PKP-RO is pretty limited compared to adding something to JS or WebCrypto which would just ping back with the exact cert chain received. This use case seems best addressed elsewhere rather than bolted onto this spec. Hence, given the concern that this spec is already bloated, I would advocate we seriously consider dropping -RO mode completely. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On 26 August 2014 17:10, Chris Palmer pal...@google.com 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 ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Tue, Aug 26, 2014 at 7:07 PM, Tom Ritter t...@ritter.vg wrote: Just because I have a concern or preference doesn't mean I don't really appreciate the work you've done. I do. Well said. 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). My email wasn't very clear but I would also prefer this policy; I was simply trying to say that if this isn't possible or acceptable dropping it completely might be preferable to the current version. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On Tue, Aug 26, 2014 at 5:15 PM, Joseph Bonneau jbonn...@gmail.com wrote: 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). My email wasn't very clear but I would also prefer this policy I'd prefer this as well. To be even clearer, I think the browser should treat PKP and PKP-RO headers independently. I.e., the browser should maintain separate stores for PKP and PKP-RO data. PKP headers only affect the PKP store, and PKP-RO headers only affect the PKP-RO store. (For example, PKP max-age=0 doesn't clear PKP-RO, and vice versa). A browser implementing this probably already has separate stores for HSTS and HPKP, so this is just adding a third for HPKP-RO, which seems reasonable to implement. Trevor ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] Re-litigating Key-Pinning
Hi folks In the last few days, we’ve had a bunch of threads re-opening issues with key-pinning, mostly around the PKP-RO. This document has gone through years of discussion on the mailing list, a WGLC and an IETF LC. The document is now under review by the IESG. We (the working group) and the authors need to address comments and discuss ballots by members of the IESG. This is an inappropriate time to raise new substantive issues about the document. Fixing editorial issues like Julians’ comments about references is fine, and could even be done *after* IESG review. However, making substantive changes like removing PKP-RO or changing the requirements for processing it cannot be done at this stage. Deciding to do this requires withdrawing the publication request and sending it back to the working group. I do not think this is advisable. The IETF occasionally publishes documents that are imperfect. Such imperfections can be fixed later via errata or -bis documents. For now, I think we should publish the document as it is with the changes agreed upon in discussions with ADs. Thanks Yoav [with chair hat firmly on] ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
