Re: [websec] Requiring OCSP Stapling as a directive in HSTS
On 19 January 2015 at 13:17, Ryan Sleevi ryan-ietfhas...@sleevi.com wrote: On Mon, January 19, 2015 9:55 am, Tom Ritter wrote: The threat model I'm trying to address is an attacker who can get a valid certificate misissued for a domain. Because of the revocation situation, the attacker can then MITM users with impunity, blocking revocation lookups if they occur. While UAs would receive a crlset or other push of revoked certificates, I believe that the UA will still work if that connection is blocked, and it's not clear how long that connection must be blocked before the UA stops working entirely. (If that happens at all.) In this threat model, where does NTP fit? It seems like you're assuming the attacker can intercept both the target site and the UA's distribution mechanisms, so I would presume that they're also privileged enough to mount NTP attacks? That's true. It would be broken by NTP and an attacker attaching an older OCSP staple. (Similarly, an attacker could use an old staple and a previously compromised certificate, one since expired.) The best proposal I've heard for fixing NTP was using TLS (either in the protocol or an HTTP Date header) for broad resolution plus NTP for fine-grained skew. I'd love to see OSes and/or UAs adopt it. While I'm not opposed to making the language say Hard Fail Revocation Checking I would expect UAs to interpret that as OCSP stapling, and would not want to delay implementation to account for unlikely-used corner cases. And if we say OCSP Stapling, there's no reason that down the road we could add a new directive for 'hard-fail-revocation' and let it encompass many different checks. To make sure this is clear: You're suggesting hard-fail OCSP checking when the OCSP directive is present in the header (always), and you're just quibbling over the naming of that directive here, right? I'm just making sure, since soft-fail OCSP stapling doesn't seem to make a lot of sense? I'm definitely not proposing soft-fail anything. I was dancing around options for what the directive would mean, trying not to be too religious about it: a) Call it Require OCSP Stapling b) Call it Require Hard Fail Revocation Checking and UAs really implement it as requiring a Staple c) Call it Require Hard Fail Revocation Checking and UAs implement it as requiring a CRL, Staple, or Successful OCSP query I like (a), followed by (b), and least of all (c). I think (c) is the most work and is going backwards from what UAs seem to want - so least likely to be implemented. As far as 'Where?' and why 'In HSTS'? I see four options: a HTTP Header, a TLS Extension, a DNSSEC record, and a Certificate Extension. You missed a fifth. A .well-known URI (RFC 5785) used to configure security-policy at the domain level. I don't suggest this as something that the browser would background fetch (although certainly, it could be induced so coupled with a header). I'm not sure I understand: there's a .well-known URL that says Must Staple _and_ a header? Moreso, I'm suggesting that this be used to build such preload lists of security policy so that they can be distributed. I'm not sure I understand you entirely, but if you're suggesting that the crawl + browser preload is the mechanism by which this is deployed, I'm kind of 'meh' on that. It relies on a site operator inducing a company to crawl their site and bake the policy into the software somehow. It feels like taking something that's two-party (site operator and user agent) and making it three (adding user agent infrastructure and crawling robots). The failure mode of a bad HSTS header is not too bad - you're stuck on TLS. If accidentally set / by an attacker / things really hit the fan, you could stick one of the many CDNs in front of your site to handle the TLS to your unencrypted backend. The failure mode of a bad HPKP header is decidedly worse - total site denial if you do key rotation / change CAs. Preloading is one way to mitigate this (by providing some consistent view of effective policy), although even that can be botched (e.g. CryptoCat recently rotated CAs and thus committed pinning suicide, at least until Chrome 41). The security considerations of hostile pinning alone accounted for quite a bit of discussion. OCSP stapling I think falls somewhere in the middle here on the risk proposition - there's still a vast, depressing majority of server software that doesn't support OCSP stapling. What are the implications for server admins who botch it themselves or who are attacked? I'm much more concerned by the former, see it much more likely, and think it's much more likely to result in self-inflicted DOS. For example, configuring ngingx to serve an OCSP response, but then forgetting to setup the cron job to rotate it = site inaccessible once the response expires (presuming hard fail, which I think is the sensible path) DoS is definitely something
[websec] Requiring OCSP Stapling as a directive in HSTS
Hi all. I'd like to propose an idea: add an optional directive to the
HSTS header that, when included, mandates any certificate received for
a domain require OCSP Stapling. It would respect includeSubdomains and
max-age.
The threat model I'm trying to address is an attacker who can get a
valid certificate misissued for a domain. Because of the revocation
situation, the attacker can then MITM users with impunity, blocking
revocation lookups if they occur. While UAs would receive a crlset or
other push of revoked certificates, I believe that the UA will still
work if that connection is blocked, and it's not clear how long that
connection must be blocked before the UA stops working entirely. (If
that happens at all.)
Counting from the detection of the attack (which efforts like CT and
Pinning help detect), requiring OCSP stapling changes the window of
attack from {forever?, 30 days?, an unknown value?} to the OCSP
staple's lifetime. (Assuming the attacker gets a OCSP signature right
before revocation.)
Why OCSP stapling and not require the UA to instead use 'hard-fail'
revocation checking? Well, CRLs have all sorts of drawbacks: longer
expiry times, large sizes, and they're pretty much being phased out
everywhere. (I know about Delta-CRLs - developing a specification for
them, implementing, and deploying them will take years, if ever, due
to IPR stuff. This does not.) What about requiring OCSP querying?
Browsers don't much care for that - it's slow, can timeout for
non-security reasons, it's out of the control of the web site owner.
That leaves us with OCSP Stapling - it's fast, implemented, deployed.
While I'm not opposed to making the language say Hard Fail Revocation
Checking I would expect UAs to interpret that as OCSP stapling, and
would not want to delay implementation to account for unlikely-used
corner cases. And if we say OCSP Stapling, there's no reason that
down the road we could add a new directive for 'hard-fail-revocation'
and let it encompass many different checks.
As far as 'Where?' and why 'In HSTS'? I see four options: a HTTP
Header, a TLS Extension, a DNSSEC record, and a Certificate Extension.
Certificate Extension is being worked on
(https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/) but I
see it as a compliment to this. The certificate extension only
dictates policy for this certificate. If we assume an attacker can
get a misissued certificate for a domain, the cert extension is only
useful when it is the default issuing status and an attacker must have
additional privledges to circumvent it. And it doesn't make sense to
have a certificate extension dictate policy for a whole domain, that's
a very strange location to put this sort of data.
A DNSSEC record has deployment problems, we can't retrieve it
reliably. Fallback or soft-fail provides no security and is useless
here.
A TLS Extension makes a certain amount of sense. We're trying to
dictate a policy for TLS connections, not HTTP. But it's more
difficult to deploy TLS Extensions than HTTP headers, the TLS working
group is tremendously busy, and technically this would fit more with
the closed PKIX group.
That leaves us with a HTTP Header. I think it makes more sense to put
this as a directive on HSTS rather than making a new header. While I
could imagine situations where one would want to require revocation
checking (or pinning for example) without requiring TLS, I don't see
it as a huge use case. Rather, putting it in HSTS is a small
incremental upgrade that avoids redefining all the other stuff.
Should the UA require a staple for all certs in the chain
(Intermediates included) or just the leaf? I'm not religious about
one or the other, I'd probably lean towards requiring all but I'd need
to review the implementation and deployment status of multi-stapling.
Just requiring the leaf is simpler from a deployment perspective I
believe, and compromised intermediates cause immediate browser pushes
anyway.
Would there be support for this draft?
-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?
On 7 November 2014 13:28, Xiaoyin Liu xiaoyi...@outlook.com wrote: For instance, if Twitter wants to gracefully switch to HTTP. It needs to send max-age=0 for twenty years in order to ensure that no one is locked out. But planning ahead twenty years is impossible. So for Twitter switching from twenty years to infinity doesn't add more risks. With something concrete, Paypal just jumped to 2 years: https://twitter.com/equalsJeffH/status/530840852243832833 Maybe Jeff can weigh in on what it took to get to that confidence level and whether he/they would rather have 'infinite'. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
On 27 August 2014 05:46, Yoav Nir ynir.i...@gmail.com wrote: At this stage, we can make editorial changes, but we cannot make significant changes on our own. We can withdraw the request to publish, and take it back to the working group, but I think that would be inadvisable. I think we should proceed, making only editorial changes, and changes resulting from discussion with IESG members. If adding a note in 4.2 about includeSubdomains and PKP-RO (for testing) counts as editorial, I think that is worthwhile. Otherwise/regardless I also don't want to withdraw. -tom ___ 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 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 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 25 August 2014 13:07, Eric Lawrence ericlaw1...@hotmail.com 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. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] First Connection Active Attack in HPKP
On 28 April 2014 19:51, Chris Palmer pal...@google.com wrote: I see your point... is the attack so marginal that it doesn't matter either way? I'm not sure I feel strongly any more on this topic. I would call the difference marginal only if the we never envision the report having anything done with it except immediate sending. If it's stored for later, logged, a browser extension collects them all and sends them out through Tor or some other mechanism... then I would say it's not marginal. And since those are possibilities, I would say it would be better to remove the paragraph and not have different behavior. It would also probably make the code simpler, too. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Public-Key-Pins-Report-Only
On 5 April 2014 14:37, Trevor Perrin tr...@trevp.net 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 tThe 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 tWhen 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 tHosts 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 tNote that the report-uri need not necessarily be in the same Internet domain or web origin as the Known Pinned Host./t tUAs 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 tUAs 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: tUAs 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. tIf 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 tIf 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
Re: [websec] Public-Key-Pins-Report-Only - attempt at summary
On 27 February 2014 16:07, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 02/27/2014 03:31 PM, Trevor Perrin wrote: 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, is applied to includeSubdomains), but only generates reports instead of hard fails. The browser would store PKP and PKP-RO pins in separate/parallel stores, for example setting max-age=0 for a PKP pin would not clear PKP-RO pins, and vice versa. 2) PKP-RO is removed from the spec. 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics (only check current connection). I'm not sure about the usefulness of that, and I worry site operators would be mislead by it. As someone who sometimes helps to operate and plan the operation of web sites, i don't think the semantics of (3) are misleading, but they're not particularly confidence-inspiring either. What is the goal of PKP-RO? Is the goal to encourage adoption by giving site operators confidence in a proposed configuration or organizational workflow? As I believe - this. PKP-RO doesn't enforce security for a site, and while a PKP header MAY be saved for later reporting* - an attacker performing a man-in-the-middle attack can block a PKP-RO assignment or a PKP-RO report. (At least, right now, I have a suggestion for this below.) * From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3 So I feel it's primarily for testing a configuration and gaining confidence in it before rolling it out. The real footgunnery with PKP will come during key transition/rollover (or switching CAs), as clients who have cached pins cope with the changes. Using (3)-style PKP-RO to build confidence in an organizational workflow around this kind of transition event doesn't seem possible. I agree. So I'm for #1 - store it. I have afew suggestions around fixing up portions of the doc for this. The PKP-RO header MUST be able to be cleared out at any time by setting max-age=0 if the connection occurs over an error-free TLS connect excepting any requirement of matching a key to a PKP-RO header. Explained, I should be able to clear out an old PKP-RO header even if I set the hash to DEADBEEF and the max-age to a year. The PKP-RO header reports MAY be stored for reporting at another time. I don't think browsers will implement this right away, but down the line I think it might turn into an actual security feature. A report SHOULD be generated and transmitted (or stored) before clearing out an old policy. (So bad is I get an extra report I ignore, good is that an attacker can't definitively silence a report if it is stored for later.) When I recieve reports, I can tell what the PKP-RO policy was at the time by examining the report. Except that the report needs to have a new field in there saying if it's mode is 'enforcement' or 'report-only'. As a site operator, I can even go farther by specifying a non-hash such as sha256=policytest20140301v1 - no one will be able to gen a cert that hashes to a b64 representation of that, and it lets me track my policy deployments if I like. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Pre-loaded pins vs dynamic pins
On 19 February 2014 16:14, Chris Palmer pal...@google.com wrote: On Wed, Feb 19, 2014 at 12:09 PM, Yoav Nir y...@checkpoint.com wrote: Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way. I don't object; I like that well enough. Seconded/Thirded/Fourthed -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] WGLC for draft-ietf-websec-key-pinning-10
On Feb 19, 2014 6:05 PM, Chris Palmer pal...@google.com wrote: And that deployment would actually be made more confusing, not less, by having two analogous headers, named in the same pattern, that behave differently - I think that's likely to cause as much confusion as anything else. Yeah, I see that. I think I'll have to change the text to allow the CSP-style enforce 1 policy, report on another behavior. So, how about this: tIf 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 and And the pins is a typo. I'm not clear what note means in this context. You probably mean not ignore, but I don't know the least ambiguous verb to use? In any event, I like the sentiment. 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 (Sent on a phone) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HPKP: The strict directive and TLS proxies
On 29 November 2013 15:24, Trevor Perrin tr...@trevp.net wrote: * Why is there a Public-Key-Pins-Report-Only header instead of a report-only directive? Most of the document is written as if there was a single PKP header field, so a directive would make more sense. If it becomes a directive, we should be sure that we can still apply two headers, one more loose in enforcing mode, one stricter in report only mode. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HPKP: The strict directive and TLS proxies
On 29 November 2013 17:39, Trevor Perrin tr...@trevp.net wrote: On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter t...@ritter.vg wrote: On 29 November 2013 15:24, Trevor Perrin tr...@trevp.net wrote: * Why is there a Public-Key-Pins-Report-Only header instead of a report-only directive? Most of the document is written as if there was a single PKP header field, so a directive would make more sense. If it becomes a directive, we should be sure that we can still apply two headers, one more loose in enforcing mode, one stricter in report only mode. Would you expect both headers to be noted? The current spec doesn't support that. It specifies 2 different (and incompatible) ways of handling this case: - 2.1.3: If a Host sets both the Public-Key-Pins header and the Public-Key- Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins- Report-Only header. - 2.3.1: If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field. Oh yea. Heh. Why is that? CSP supports an enforcing header and a reporting header, and both of them are applied simultaneously. I would expect the same from HPKP. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HPKP: The strict directive and TLS proxies
On 11/19/2013 3:36 PM, Yoav Nir wrote: As far as the laptop moving between home and work... I get the impression this situation may be regarded as a 'failure' of the protocol. That is, we have unintentionally broke something. I disagree. I think the situation has worked as desired. It's the other way around. The desktop that remains at the office and keeps ignoring the strict pins is the failure. Ah, I agree with that, also. I was anticipating an argument that the laptop had been 'broken' by the migrating. So the benevolent TLS proxy should note the strict directive and block the connection by itself? It makes sense, but that would require an upgrade of the TLS proxies. Changing client behavior would work with the proxies that are deployed now. Not necessarily. Really I meant that I, as the maintainer of the SSL MITM device at FooCorp could decide Employees aren't allowed to use personal WebMail at work and then enforce that with blocking. Auto-Blocking based off 'strict' would absolutely require upgrades, but that wasn't my meaning. I expect that Firefox and Google may even continue to preload entries in their browsers that apply the 'strict' directive specifically to provide websites the power to assert their right to a MitM-free connection. I know several websites who would like to exercise that right. What? And have their sites not work in all the places that have newer firewalls? I doubt it. /shrug I can hope. :) -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HPKP: The strict directive and TLS proxies
Hm. Interesting predicament. Two thoughts: If the goal is to allow clients to note and obey the 'strict' directive even in the face of a SSL Interception proxy... what you propose won't work. The proxies will be built to just remove the strict directive, or the header all together. If the organization running the proxy wanted to block access to the site in question, they would do so. If they want to monitor ongoing access, they will strip the directive/header so the clients continue to connect. If they are ambivalent - 'access it or not, we don't care, but must monitor you if you do' - the stripping feature may or may not be enabled. What you propose would only help in the latter case, it will not actually provide more security if the website considers the proxy to be an adversary. And if they add the strict header, I would imagine that the website does consider them to be an adversary, or at least that they do not wish the connection to succeed.. So I don't think what you propose is worthwhile, specifically because it does add risk via sites bricking themselves, while not improving security considerably. As far as the laptop moving between home and work... I get the impression this situation may be regarded as a 'failure' of the protocol. That is, we have unintentionally broke something. I disagree. I think the situation has worked as desired. Because if we replace the players with a rogue government performing TLS MitM, with the specific goal of isolating clients from receiving up-to-date security policies... we would declare this same situation a success. I don't see a way to reconcile the two situations, as they behave almost exactly the same. TLS Proxies add a third player into what was previously a (primarily) two-party protocol*. I think the strict directive preserves the reasonable property that any one of the three parties can choose not to participate based on the settings of the protocol. - The TLS proxy can block access or choose not to intercept - The user can not visit the site - The site can declare I don't want anyone else seeing the data I consider to be for the user's eyes only I expect that Firefox and Google may even continue to preload entries in their browsers that apply the 'strict' directive specifically to provide websites the power to assert their right to a MitM-free connection. I know several websites who would like to exercise that right. -tom * Yes yes, CAs make 3, but that's PKIX, not TLS. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Consensus call: Issue #57 (max-max-age)
On 7 May 2013 03:13, Yoav Nir y...@checkpoint.com wrote: How should we handle the max-max-age issue: (1) No hard limits, but allow UAs to limit the pin time. Suggest a month (2) Set a hard limit of one month in the RFC. Longer pins are truncated. (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month) (4) Adopt some gradual confidence-building scheme a-la-TACK. None of the above is possible, but MUST come with argument and proposed text. None of the above: No hard limits, leave limiting the pin time unspecified, make no suggestion. I don't believe any text changes are necessary. I think UAs that are sufficiently worried about websites bricking themselves come up with creative solutions that work well for them, but may not be applicable to others. (Chrome's will (or would) expire hardcoded pins if there hasn't been a Chrome update in a month - they could do the same for max-ages.) I don't like the idea of suggesting that UAs unilaterally override a site's possible desire to pin for more than 1 month. -tom. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #55: Clarify that the newest pinning information takes precedence
The UA MUST evict all expired Known Pinned Hosts if at any time, an expired Known Pinned Host exists in the cache I use rrdtool to keep 5 years of statistics for my server. Once, I accidentally set the date forward, to 2038, wiping out my statistics - there was no way to recover, because rrdtool dutifully wiped all this expired data. Using the word 'evict' seems particularly dangerous, for both active ntp attacks, and accidental wiping. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
On 18 October 2012 21:15, Chris Palmer pal...@google.com wrote: I think it's reasonable enough. However I did add this: The UA MUST note the pins if and only if it received the Public-Key-Pins response header field over an error-free TLS connection. The UAs MUST ignore Public-Key-Pins response header fields received on HTTP (non-HTTPS) connections and on HTTPS connections that are not error-free. to (hopefully) resolve this: Similarly, I wonder if there was some situation that could result in an attacker-induced 'errored' TLS connection that still sent the header, resulting in the data being discarded... Thoughts? Sorry, but I think that introduces more confusion. Point 1 includes a criteria and a Do Something if not Criteria but the following paragraph after the Criteria also includes a Do Something if not Criteria. I would suggest moving the do something out of the first criteria. I would suggest the following, which moves the 'do something' out of criteria 1, clarifies that the discarding action only applies to currently Pinned Hosts, and states explictly that when we say error-free TLS this includes the validation in Section 2.4 if applicable. The UA MUST observe these conditions when noting a host: o The UA MUST note the pins if and only if it received the Public-Key-Pins response header field over an error-free TLS connection. If the host is a Pinned Host, this includes the validation added in Section 2.4 o The UA MUST note the pins if and only if the TLS connection was authenticated with a certificate chain containing at least one of the SPKI structures indicated by at least one of the given fingerprints. (See Section 2.4.) o The UA MUST note the pins if and only if the given set of pins contains at least one pin that does NOT refer to an SPKI in the certificate chain. (That is, the host must set a Backup Pin; see Section 3.1.) If the Public-Key-Pins response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host. A Public-Key-Pins response header field that meets all these critera is known as a Valid Pinning Header. The UAs MUST ignore Public-Key-Pins response header fields received on connections that do not meet the first criteria. If the UA recives a Public-Key-Pins header from a Pinned Host that meets the first criteria, but not the following two, the UA MUST discard any previously set Pinning Metadata for that host in its non-volatile store. 2.5: Pin Validity Times I find the current + current - initial / (b) the amount of time the pin has been noted item confusing, and am not sure what it means from reading only the draft. If I'm not the only one, it might be worth clarifying. Yes, even after a lot of thought I am still undecided about this. I see several possible approaches: (a) simply have the validity time be the same as for HSTS; (b) the same as HSTS but with a 30-day maximum; (c) the current attempt to mirror TACK, except clarified and with examples; or (d) something else. Of these, I think I currently like (b) best. Thoughts? I think A. I believe (without evidence) there are institutions that would eventually like to use this that have customers that work with them on a quarterly or annual basis. Likewise, I believe (without evidence) that a institution who was risk adverse would mitigate that risk by pinning to several large CA roots, not by saying Oh well our customers can't access us for the next 30 days, but it's only 30 days who cares - but 60, that would be unacceptable! I do like TACK's notion of 'growing' out pins but only in a That sounds like a feature we're anticipating people wanting way. If people actually hold off on deploying this because of that and that alone, it SHOULD be possible to add a new directive, ignored by older browsers who don't implement it. Public-Key-Pins: max-age=600; grow-to=86400; pin-sha1=4n972HfV354KP560yw4uqe/baXc=; The spec should probably note that directives not understood should be ignored, and not invalidate the header, to allow for future expansion. Right? I think you mean clears dynamic pins? Yes, dynamic pins. I don't consider the implicit tracking cookie problem to be solvable. I think EFF's Panopticlick conclusively shows that it cannot be solved. ... I suppose we could press the Safe Browsing list into service for this (and data and API for that are open), but it's a stretch. SB is about malware and phishing, which is a different thing than implicit tracking. I was actually saying Chrome shouldn't ship preloaded pins for Marketing Firms, because if a MF sends Pins to a user in Incognito Mode, then the user closes Incognito Mode - MF can learn that a user is a repeat visitor even though they visited in Incognito Mode. But AFAICT that would be all the information a Marketing Firm would be able to learn - binary visited or not.
Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
Some musings after reading again: Section 2.3 Noting Pins: I wonder if it is worth moving The UAs MUST ignore Public-Key-Pins response header fields received on HTTP (non-HTTPS) connections. outside the criteria to be unambiguous that a client should not discard any previously set Pinning Metadata if it receives the header over HTTP. Or if it's reasonable enough to assume no one would get confused. Similarly, I wonder if there was some situation that could result in an attacker-induced 'errored' TLS connection that still sent the header, resulting in the data being discarded... Section 2.4: Validating Pinned Connections: For the purposes of Pin Validation, the UA MUST ignore certificates who SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain. I know I just modified this, but the second phrase just hit me. Because path construction is non-standard, could a client wind up in a situation where the site pinned to CA_Alice, with the intended path CA_Alice - CA_Bob - Intermediate - Leaf; but because CA_Bob was trusted, the ultimate validating chain was simply CA_Bob - Intermediate - Leaf? I'm not sure what the right way to counteract that would be... 2.5: Pin Validity Times I find the current + current - initial / (b) the amount of time the pin has been noted item confusing, and am not sure what it means from reading only the draft. If I'm not the only one, it might be worth clarifying. 2.6. Interactions With Preloaded Pin Lists If closing private browsing mode or clearing saved data also clears preloaded pins (and I think it should), this would cause a revert to the preloaded pins, which may break sites. A workaround may be to disable a preloaded pin if a new pin is seen, and keep that disabled even after the saved data wipe/private browsing mode close. To prevent using this as a backdoor into tracking, the preloaded pins should be sanity checked for Is this organization likely to abuse the feature. Again, excited about this - thanks for the work. -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] handling STS header field extendability
On 10 August 2012 17:52, Chris Palmer pal...@google.com wrote:
Please forgive my ignorance, but do LockCA and/or LockEV offer any
functionality that you can't already get with public key pinning as
currently specified? You can pin to a given CA's public key(s), and
you can pin to any given EV issuers' public keys.
I can't think of one for Lock CA; but LockEV could be useful for sites
that want to deploy some additional measure, but can't/don't want to
a) commit to a CA or b) enumerate all possible EV authorities. It
should be ('should be', not 'is') more difficult to get a fraudulent
EV certificate through trickery or treachery than a DV certificate.
I don't think browsers differentiate between OV and DV in any
meaningful way, but I could be wrong.
-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [saag] Pinning
I don't know IETF procedure for making changes, but one of the outstanding issues I don't think has been resolved with draft-ietf-websec-key-pinning-02 is inherited DSA parameters. I raised this issue here: http://www.ietf.org/mail-archive/web/websec/current/msg01027.html with suggested verbiage. -tom On 11 August 2012 16:37, Yoav Nir y...@checkpoint.com wrote: Hi Chris I've removed SAAG from CC, trimmed most of your message, and re-arranged the rest. Hope you don't mind… On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote: Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. hat type=chair Just as a reminder, HPKP is now a working group draft. As such, change control is with the WG. Changes that change the rules for activation and expiration should be proposed and discussed on the list first. Having said that, we are pretty far from last call on key-pinning, so I think it would be OK to publish a version -03 with such proposed changes, as long as those changes are clearly marked as not being the result of WG consensus. /hat As an individual, I understand the limitations of the spare public key approach of the current HPKP. It's an administrative hassle to generate n spare keys and keep them safe, and if you have n+1 key compromise events within the max-age time, your site is blocked. But it does have the big advantage that the server side can be deployed *now* with no additional software. Until I see how those borrowed ideas can help with these issues, I prefer HPKP. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Well, there's WG deciding, and there's the market deciding. The IETF can publish both approaches (as either proposed standard or experimental) and the one (if any) that the market prefers can later be upgraded to standard (or it can stay at proposed anyway) Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document
On Nov 17, 2011, at 5:03 PM, Adam Barth wrote: Support. +1 -tom ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
