Yoav Nir | 27 Aug 07:44 2014
Picon

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]
Julian Reschke | 26 Aug 12:18 2014
Picon
Picon

draft-ietf-websec-key-pinning-20 POST report format

Hi there,

this is about 
<http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-3>.

1) I believe it would be good if the example actually showed the full 
POST request so that it contains the media type.

2) Speaking of which: I assume the media type is supposed to be 
application/json?

Also, this essentially introduces a mechanism by which the UA will 
automatically send an unsafe HTTP request (POST) to a server which might 
have a different origin than the server triggering this. Are we sure 
that this doesn't introduce a new exploit? Maybe it would be better to 
at least use a non-generic media type instead?

Best regards, Julian

Julian Reschke | 26 Aug 10:56 2014
Picon
Picon

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
(Continue reading)

Julian Reschke | 26 Aug 10:55 2014
Picon
Picon

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

Ryan Sleevi | 25 Aug 08:09 2014
Picon

User interactivity requirements

From someone who sent directly to the editors, and thus I've omitted their address/name on the assumption of privacy.

In section "2.6. Validating Pinned Connections" there is written:
   When a UA connects to a Pinned Host, if the TLS connection has
   errors, the UA MUST terminate the connection without allowing the
   user to proceed anyway.  (This behavior is the same as that required
   by [RFC6797].)
I think that "(This behavior is the same as that required by [RFC6797].)" is misleading, because RFC6797 states that its section 12 (which contains "12.1. No User Recourse") is non-normative.
http://tools.ietf.org/html/rfc6797#section-12

Indeed, this is an oversight, and one that's arguably in conceptual conflict with the paragraph that follows, which describes Pin Validation as a SHOULD.

That is, one can imagine that a TLS connection that is being actively MITM'd by a locally-installed trust anchor MAY induce other TLS errors. As the UA will not be performing pin validation, it's not clear that the UA should also be inheriting the requirement for non-procession.

That is, HSTS DOES have a normative requirement on termination (see http://tools.ietf.org/html/rfc6797#section-8.4 ), which HPKP should also have, but whether or not a user can proceed is non-normative and up to implementations (with a general recommendation that the user should not be permitted to proceed)
<div><div dir="ltr">
<div>
<div>From someone who sent directly to the editors, and thus I've omitted their address/name on the assumption of privacy.</div>
<div><br></div>
<blockquote class="gmail_quote">
In section "2.6. Validating Pinned Connections" there is written:<br>&nbsp;&nbsp; When a UA connects to a Pinned Host, if the TLS connection has<br>&nbsp;&nbsp; errors, the UA MUST terminate the connection without allowing the<br>&nbsp;&nbsp; user to proceed anyway.&nbsp; (This behavior is the same as that required<br>
&nbsp;&nbsp; by [RFC6797].)<br>I think that "(This behavior is the same as that required by [RFC6797].)" is misleading, because RFC6797 states that its section 12 (which contains "12.1. No User Recourse") is non-normative.<br><a href="http://tools.ietf.org/html/rfc6797#section-12" target="_blank">http://tools.ietf.org/html/rfc6797#section-12</a>
</blockquote>
<div><br></div>Indeed, this is an oversight, and one that's arguably in conceptual conflict with the paragraph that follows, which describes Pin Validation as a SHOULD.</div>
<div><br></div>
<div>That is, one can imagine that a TLS connection that is being actively MITM'd by a locally-installed trust anchor MAY induce other TLS errors. As the UA will not be performing pin validation, it's not clear that the UA should also be inheriting the requirement for non-procession.</div>
<div><br></div>
<div>That is, HSTS DOES have a normative requirement on termination (see&nbsp;<a href="http://tools.ietf.org/html/rfc6797#section-8.4">http://tools.ietf.org/html/rfc6797#section-8.4</a> ), which HPKP should also have, but whether or not a user can proceed is non-normative and up to implementations (with a general recommendation that the user should not be permitted to proceed)</div>
</div></div>
Ryan Sleevi | 25 Aug 08:03 2014
Picon

Re: draft-ietf-websec-key-pinning




On Fri, Aug 8, 2014 at 1:50 PM, Eric Lawrence <ericlaw1979 <at> hotmail.com> wrote:
-------
In several places, the text seems to suggest that PKP-RO rules are not intended to be cached within the UA. Is that the case? If so, this isn't explicit; max-age should be forbidden.
 
In contrast, if PKP-RO rules are allowed to be cached within the UA, then the following should be removed:
 
   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.
 
... because the site may wish to disable a previously-cached PKP-RO entry.

No, PKP-RO is not meant to be cached. In this respect, it behaves similar to Content-Security-Policy's reporting mechanism.

I'm not sure if you're suggesting forbidden - such as treating the header as ill-formed, ergo not sending a report - or merely ignored. I feel like #6 of Section 2.1 already reflects this, but would be happy to add specific text directly stating that max-age is IGNORED for PKP-RO.
 
 
-------
2.3.1. 
 
RO header fieled
-
typo, fieled->field
 
-------
2.5
   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.
-
If the failing criteria was "cert chain didn't contain at least one of the SPKI signatures", should this trigger a report to the report URI to aid developers and/or enable some amount of protection for sloppy attacks (or captive/corporate MITM interception, etc) against 1st-time visitors?


When used in the PKP or PKP-RO headers, 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 Section 2.6).
 
 
-------
2.6.  Validating Pinned Connections
   When a UA connects to a Pinned Host, if the TLS connection has
   errors"
-
This probably should be "connects to a Pinned host using TLS connection" since PKP does not require that the user connect via a secure connection.

Thanks, yes.
 
 
-------
"If the connection has no errors, then the UA will determine whether
   to apply a new, additional correctness check: Pin Validation"
-
Should this wait until the TLS validation has fully completed, or should it happen before the client potentially responds to a clientCertificateRequest from the server?

The implementations are already consistently-inconsistent in this respect. That is, both Chrome and Firefox do this during certificate validation, but for timing reasons, certificate validation occurs at different times.

Both are currently allowed.
 
 
-------
For example, a UA may disable
   Pin Validation for Pinned Hosts whose validated certificate chain
   terminates at a user-defined trust anchor, rather than a trust anchor
   built-in to the UA.
-
Might it be useful to explain the motivation here, however briefly? I'm super-happy to see this here (Fiddler!), but most UAs don't have trust anchors built-in, they rely on the operating system to provide them.
 

Well, this was merely meant as one representative example, not necessarily a normative recommendation. That is, one could equally add "For example, a UA without built-in trust anchors may also decide to ..." and still be consistent with the normative SHOULD - that is, the examples are non-exhaustive.

Still, happy to expand this text further, as I suspect this is just an unintentional use of restrictive terminology (i.e. a UA can do this even when it defers to the OS trust store)
 
-------
The UA MUST ignore superfluous certificates in the chain that do not form part of the validating chain.
-
As far as I understand things, there can be multiple valid chains to multiple roots. Should the validation procedure be required to check each possible candidate chain?

Neither RFC 5280 nor RFC 5246 require UAs to evaluate all candidate chains. Indeed, there's enough controversy from parties in TLS that I suspect there is not clean resolution in either event.

In the UA sphere, not all UAs consider candidate chains. Mozilla Firefox, before version 31 (implementing mozilla::pkix) did not consider all candidate chains. 31+, it does, and it does the pinning check during the evaluation of potentially valid candidate chains.

Google Chrome defers to the OS for the chain building, which OS X does not consider candidate chains, but Windows does. However, Windows lacks a suitable means for calling back on evaluating candidate chains. As a result, Chrome performs validation after the candidate chain has been declared "successful".

So the answer is "No, it should be required"
 
 
-------
locally-installed anchor
-
This should probably be "user-defined trust anchor" to match the earlier prose.
 
-------
"served-certificate-chain": [
       pem1, ... pemN
     ],
-
Privacy: This could leak organizationally-private information; say the user's company is using BlueCoat or another intercepting proxy with interception certificates that contain data that should not leave the organization.

Funny that this spec would consider the privacy of the attacker (as such situations are indistinguishable from an attack on the pins).

Still, happy to call it out specifically.
 
 
-------
"include-subdomains": include-subdomains,
-
This field could be misleading, as the JSON report contains the hostname that the user visited, which may differ than the host that originally set the rule if include-Subdomains was set on that rule.

Good point. This suggests that the JSON may need to indicate both the target hostname and the source (of the PKP data) hostname.
 
 
-------
indeed could pin to issuers not in the chain
-
Per the spec, they indeed MUST include a pin to an issuer not in the chain
 
-------
4.4.  Interactions With Cookie Scoping
-
I'll mention that IE sends cookies to subdomains even when a domain attribute isn't present. Q3: http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx
 
This section suffers from the same incompleteness that Section 14 of the HSTS spec suffers: Because a rule specified on a subdomain (effective-third-level-domain) does not apply to the effective-second-level-domain, if a user visits the 3rd-level domain first or exclusively, a MITM attacker can perform a cookie-injection by generating a phony insecure request to the effective-second-level-domain and returning a Set-Cookie header in his poisoned response.

I'm not sure I understand your remark with respect to "incompleteness". This is more of an operational guidance for server operators, correct?
 
 
-------
5.  Privacy Considerations
"UAs MAY, therefore, refuse to send reports outside of the origin that set the PKP or PKP-RO header."
-
1. It seems odd to put a mitigation inside a description of the attack.

Per Stephen's DISCUSS, I think we'll be bringing this mitigation 'out' a level in the spec.
 
2. Doesn't the proposed mitigation inherently failure-prone, since the report would inevitably fail, because the origin's PKP rule would block the report?

It prevents the collusion, so that seems to effectively mitigate that particular attack, does it not?
 
 
-------
5.  Privacy Considerations
"Conforming implementations..."
-
1. This 3rd privacy attack should be bulleted as a separate point.

Agreed
 
2. Earlier, it's stated that PKPs should be stored in "non-volatile storage". In practice, I would expect UAs would ignore attempts to update PKP/PKP-RO rules while in their respective "Private Mode"s. Is that the expectation of the authors?

Update the non-volatile storage? Yes, that's what a UA would likely do.
Prevent updates to volatile storage? No, just as UAs in such modes traditionally allow a degree of volatile storage (since the modes are primarily meant to prevent disk persistence, rather than tracking). This allows, for example, session cookies to work.
 
 
Thanks!
 
-Eric Lawrence

<div><div dir="ltr">
<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 1:50 PM, Eric Lawrence <span dir="ltr">&lt;<a href="mailto:ericlaw1979 <at> hotmail.com" target="_blank">ericlaw1979 <at> hotmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div dir="ltr">
<div dir="ltr">
<div>
<div>Comments on <a title="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20" href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20" target="_blank">http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20</a>
</div>

<div>-------</div>
<div>In several places, the text seems to suggest that PKP-RO rules are not 
intended to be cached within the UA. Is that the case? If so, this isn't 
explicit; max-age should be forbidden. </div>
<div>&nbsp;</div>
<div>In contrast, if PKP-RO rules are allowed to be cached within the UA, then 
the following should be removed:</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Note: There is no purpose to using the PKP-RO header without 
the</div>
<div>&nbsp;&nbsp; report-uri directive.&nbsp; User Agents MAY discard such 
headers without</div>
<div>&nbsp;&nbsp; interpreting them further.</div>
<div>&nbsp;</div>
<div>... because the site may wish to disable a previously-cached PKP-RO 
entry.</div>
</div>
</div>
</div>
</blockquote>
<div><br></div>
<div>
<div>No, PKP-RO is not meant to be cached. In this respect, it behaves similar to Content-Security-Policy's reporting mechanism.</div>
<div><br></div>
<div>
I'm not sure if you're suggesting forbidden - such as treating the header as ill-formed, ergo not sending a report - or merely ignored. I feel like #6 of Section 2.1 already reflects this, but would be happy to add specific text directly stating that max-age is IGNORED for PKP-RO.</div>
</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div dir="ltr"><div>

<div>&nbsp;</div>
<div>-------</div>
<div>2.3.1.&nbsp; </div>
<div>&nbsp;</div>
<div>RO header fieled </div>
<div>-</div>
<div>typo, fieled-&gt;field</div>
<div>&nbsp;</div>
<div>-------</div>
<div>2.5</div>
<div>&nbsp;&nbsp; If the PKP response header field does not meet all three of 
these</div>
<div>&nbsp;&nbsp; criteria, the UA MUST NOT note the host as a Pinned Host. 
</div>
<div>-</div>
<div>If the failing criteria was "cert chain didn't contain at least one of the 
SPKI signatures", should this trigger a report to the report URI to aid 
developers and/or enable some amount of protection for sloppy attacks (or 
captive/corporate MITM interception, etc) against 1st-time visitors?</div>
</div></div></div></blockquote>
<div><br></div>
<div>Doesn't&nbsp;<a href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.1.3">http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.1.3</a> already accomplish this?</div>
<div><br></div>
<div>   When used in the PKP or PKP-RO headers, 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 <a href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.6">Section 2.6</a>).</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>2.6.&nbsp; Validating Pinned Connections</div>
<div>&nbsp;&nbsp; When a UA connects to a Pinned Host, if the TLS connection 
has</div>
<div>&nbsp;&nbsp; errors"</div>
<div>-</div>
<div>This probably should be "connects to a Pinned host using TLS connection" 
since PKP does not require that the user connect via a secure connection.</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>Thanks, yes.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>"If the connection has no errors, then the UA will determine whether</div>
<div>&nbsp;&nbsp; to apply a new, additional correctness check: Pin 
Validation"</div>
<div>-</div>
<div>Should this wait until the TLS validation has fully completed, or should it 
happen before the client potentially responds to a clientCertificateRequest from 
the server?</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>The implementations are already consistently-inconsistent in this respect. That is, both Chrome and Firefox do this during certificate validation, but for timing reasons, certificate validation occurs at different times.<br>
</div>
<div><br></div>
<div>Both are currently allowed.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>For example, a UA may disable</div>
<div>&nbsp;&nbsp; Pin Validation for Pinned Hosts whose validated certificate 
chain</div>
<div>&nbsp;&nbsp; terminates at a user-defined trust anchor, rather than a trust 
anchor</div>
<div>&nbsp;&nbsp; built-in to the UA.</div>
<div>-</div>
<div>Might it be useful to explain the motivation here, however briefly? I'm 
super-happy to see this here (Fiddler!), but most UAs don't have trust anchors 
built-in, they rely on the operating system to provide them.</div>
<div>&nbsp;</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>Well, this was merely meant as one representative example, not necessarily a normative recommendation. That is, one could equally add "For example, a UA without built-in trust anchors may also decide to ..." and still be consistent with the normative SHOULD - that is, the examples are non-exhaustive.<br>
</div>
<div>
<br class="">Still, happy to expand this text further, as I suspect this is just an unintentional use of restrictive terminology (i.e. a UA can do this even when it defers to the OS trust store)<br>
</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div dir="ltr"><div>

<div>-------</div>
<div>The UA MUST ignore superfluous certificates in the chain that do not form 
part of the validating chain. </div>
<div>-</div>
<div>As far as I understand things, there can be multiple valid chains to 
multiple roots. Should the validation procedure be required to check each 
possible candidate chain?</div>
</div></div></div></blockquote>
<div><br></div>
<div>Neither RFC 5280 nor RFC 5246 require UAs to evaluate all candidate chains. Indeed, there's enough controversy from parties in TLS that I suspect there is not clean resolution in either event.</div>
<div><br></div>
<div>In the UA sphere, not all UAs consider candidate chains. Mozilla Firefox, before version 31 (implementing mozilla::pkix) did not consider all candidate chains. 31+, it does, and it does the pinning check during the evaluation of potentially valid candidate chains.</div>
<div><br></div>
<div>Google Chrome defers to the OS for the chain building, which OS X does not consider candidate chains, but Windows does. However, Windows lacks a suitable means for calling back on evaluating candidate chains. As a result, Chrome performs validation after the candidate chain has been declared "successful".</div>
<div><br></div>
<div>So the answer is "No, it should be required"</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>locally-installed anchor</div>
<div>-</div>
<div>This should probably be "user-defined trust anchor" to match the earlier 
prose.</div>
<div>&nbsp;</div>
<div>-------</div>
<div>"served-certificate-chain": [</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pem1, ... pemN</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; ],</div>
<div>-</div>
<div>Privacy: This could leak organizationally-private information; say the 
user's company is using BlueCoat or another intercepting proxy with interception 
certificates that contain data that should not leave the organization.</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>
<div>Funny that this spec would consider the privacy of the attacker (as such situations are indistinguishable from an attack on the pins).</div>
<div><br></div>
<div>Still, happy to call it out specifically.</div>
</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>"include-subdomains": include-subdomains,</div>
<div>- </div>
<div>This field could be misleading, as the JSON report contains the hostname 
that the user visited, which may differ than the host that originally set the 
rule if include-Subdomains was set on that rule.</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>Good point. This suggests that the JSON may need to indicate both the target hostname and the source (of the PKP data) hostname.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div dir="ltr"><div>

<div>&nbsp;</div>
<div>-------</div>
<div>indeed could pin to issuers not in the chain</div>
<div>-</div>
<div>Per the spec, they indeed MUST include a pin to an issuer not in the 
chain</div>
<div>&nbsp;</div>
<div>-------</div>
<div>4.4.&nbsp; Interactions With Cookie Scoping</div>
<div>-</div>
<div>I'll mention that IE sends cookies to subdomains even when a domain 
attribute isn't present. Q3: <a href="http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx" target="_blank">http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx</a>
</div>

<div>&nbsp;</div>
<div>This section suffers from the same incompleteness that Section 14 of the 
HSTS spec suffers: Because a rule specified on a subdomain 
(effective-third-level-domain) does not apply to the 
effective-second-level-domain, if a user visits the 3rd-level domain first or 
exclusively, a MITM attacker can perform a cookie-injection by generating a 
phony insecure request to the effective-second-level-domain and returning a 
Set-Cookie header in his poisoned response.</div>
</div></div></div></blockquote>
<div><br></div>
<div>I'm not sure I understand your remark with respect to "incompleteness". This is more of an operational guidance for server operators, correct?</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div dir="ltr"><div dir="ltr"><div>

<div>&nbsp;</div>
<div>-------</div>
<div>5.&nbsp; Privacy Considerations</div>
<div>"UAs MAY, therefore, refuse to send reports outside of the origin that set 
the PKP or PKP-RO header."</div>
<div>-</div>
<div>1. It seems odd to put a mitigation inside a description of the 
attack.</div>
</div></div></div></blockquote>
<div><br></div>
<div>Per Stephen's DISCUSS, I think we'll be bringing this mitigation 'out' a level in the spec.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>2. Doesn't the proposed mitigation inherently failure-prone, since the 
report would inevitably fail, because the origin's PKP rule would block the 
report?</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>It prevents the collusion, so that seems to effectively mitigate that particular attack, does it not?</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>&nbsp;</div>
<div>-------</div>
<div>5.&nbsp; Privacy Considerations</div>
<div>"Conforming implementations..."</div>
<div>-</div>
<div>1. This 3rd privacy attack should be bulleted as a separate point.</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>Agreed</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<div>2. Earlier, it's stated that PKPs should be stored in "non-volatile 
storage". In practice, I would expect UAs would ignore attempts to update 
PKP/PKP-RO rules while in their respective "Private Mode"s. Is that the 
expectation of the authors?</div>
</div></div></div>
</blockquote>
<div><br></div>
<div>Update the non-volatile storage? Yes, that's what a UA would likely do.</div>
<div>Prevent updates to volatile storage? No, just as UAs in such modes traditionally allow a degree of volatile storage (since the modes are primarily meant to prevent disk persistence, rather than tracking). This allows, for example, session cookies to work.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>

<div>&nbsp;</div>
<div>Thanks!</div>
<span class="">
<div>&nbsp;</div>
<div>-Eric Lawrence</div></span>
</div></div></div>
</blockquote>
</div>
<br>
</div>
</div></div>
Barry Leiba | 14 Aug 17:47 2014
Picon

DISCUSS positions on draft-ietf-websec-key-pinning

Websec folks, and especially the document authors:
We have several DISCUSS ballots on the key-pinning doc (from Stephen,
Kathleen, and Ted):

   http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ballot/

...and I have seen no response from the authors on them.  Please
respond soonest, and have the necessary discussions to resolve them.
Please also consider and respond to the non-blocking comments from
Alissa, Pete, and Richard.

Yoav, please stay on top of this and do the necessary prodding to keep
this moving.

Thanks,
Barry

RFC Errata System | 11 Aug 18:31 2014

[Errata Rejected] RFC6797 (4075)

The following errata report has been rejected for RFC6797,
"HTTP Strict Transport Security (HSTS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6797&eid=4075

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Eric Lawrence <e_lawrence <at> hotmail.com>
Date Reported: 2014-08-08
Rejected by: Barry Leiba (IESG)

Section: 14

Original Text
-------------
   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

Corrected Text
--------------
   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

   Even with the "includeSubDomains" directive, the unavailability of 
   an "includeParent" directive means that an Active MITM attacker can 
   perform a cookie-injection attack against an otherwise 
   HSTS-protected victim domain.

   Consider the following scenario:

    The user visits https://sub.example.com and gets a HSTS policy with
    includeSubdomains set. All subsequent navigations to 
    sub.example.com and its subdomains will be secure.

    An attacker causes the victim's browser to navigate to 
    http://example.com. Because the HSTS policy applies only to 
    sub.example.com and its superdomain matches, this insecure 
    navigation is not blocked by the user agent.

    The attacker intercepts this insecure request and returns a 
    response that sets a cookie on the entire domain tree using a 
    Set-Cookie header.

    All subsequent requests to sub.example.com carry the injected
    cookie, despite the use of HSTS.

Notes
-----
To mitigate this attack, HSTS-protected websites should perform a background fetch of a resource at the
first-level domain. This resource should carry a HSTS header that will apply to the entire domain and all subdomains.
 --VERIFIER NOTES-- 
This is a valid issue, but not suitable for the errata system.  The websec working group is discussing
handling this with a short document to update RFC 6797.

--------------------------------------
RFC6797 (draft-ietf-websec-strict-transport-sec-14)
--------------------------------------
Title               : HTTP Strict Transport Security (HSTS)
Publication Date    : November 2012
Author(s)           : J. Hodges, C. Jackson, A. Barth
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

=JeffH | 10 Aug 07:53 2014

fyi: State of HSTS Deployment in 2013-Oct

Here's an interesting & relevant draft paper by Lucas Garron (and Andrew 
Bortz & Dan Boneh)..

   The State of HSTS Deployment:  A Survey and Common Pitfalls
   https://garron.net/crypto/hsts/hsts-2013.pdf

Note that "S 8.5 Securing https://example.com from a subdomain" is 
essentially the issue that Eric Lawrence recently filed against RFC6797 HSTS.

The paper is worth a read, and the scan code is here..

   https://github.com/lgarron/HSTS/tree/scan

..see also the discussion in this thread on <security-dev <at> chromium.org>..

   State of HSTS in on the Web (2013)

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Ibdf-x_uqEs

HTH,

=JeffH

RFC Errata System | 8 Aug 21:05 2014

[Technical Errata Reported] RFC6797 (4075)

The following errata report has been submitted for RFC6797,
"HTTP Strict Transport Security (HSTS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6797&eid=4075

--------------------------------------
Type: Technical
Reported by: Eric Lawrence <e_lawrence <at> hotmail.com>

Section: 14

Original Text
-------------
   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

Corrected Text
--------------
   Without the "includeSubDomains" directive, HSTS is unable to protect
   such Secure-flagged domain cookies.

   Even with the "includeSubDomains" directive, the unavailability of 
   an "includeParent" directive means that an Active MITM attacker can 
   perform a cookie-injection attack against an otherwise 
   HSTS-protected victim domain.

   Consider the following scenario:

    The user visits https://sub.example.com and gets a HSTS policy with
    includeSubdomains set. All subsequent navigations to 
    sub.example.com and its subdomains will be secure.

    An attacker causes the victim's browser to navigate to 
    http://example.com. Because the HSTS policy applies only to 
    sub.example.com and its superdomain matches, this insecure 
    navigation is not blocked by the user agent.

    The attacker intercepts this insecure request and returns a 
    response that sets a cookie on the entire domain tree using a 
    Set-Cookie header.

    All subsequent requests to sub.example.com carry the injected
    cookie, despite the use of HSTS.

Notes
-----
To mitigate this attack, HSTS-protected websites should perform a background fetch of a resource at the
first-level domain. This resource should carry a HSTS header that will apply to the entire domain and all subdomains.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6797 (draft-ietf-websec-strict-transport-sec-14)
--------------------------------------
Title               : HTTP Strict Transport Security (HSTS)
Publication Date    : November 2012
Author(s)           : J. Hodges, C. Jackson, A. Barth
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

=JeffH | 9 Aug 03:01 2014

Re: cookie injection attack via superdomain of HSTS Host (was: [Technical Errata Reported] RFC6797 (4075)

[ trimming to: and cc: as I think most everyone is on websec <at>  ]

Hi Eric, thanks for submitting this errata.

Barry & everyone: actually, this issue is in S 14 "Security Considerations" 
of RFC6797, and I think Eric is correct that that subsection "14.4. The Need 
for includeSubDomains" is overlooking this detail, and hence is actually an 
errata (more or less).

However, the text I'd use to correct it would be somewhat different than 
Eric's proposed text (tho it'd build on it).

Overall, I think we discussed this aspect of things during our development 
of HSTS and rationale/defense overall amounts to..

1. HSTS Hosts really need to declare HSTS Policy at their top-level domain 
name whether or not they are reachable at other subdomains thereof and 
regardless of whether they employ .  I.e., it's  poor practice to have an 
HSTS Host at https://sub.example.com yet also answer at https://example.com 
without also declaring the latter as an HSTS Host.

In terms of there being a policy authority boundary between one's HSTS Host 
and it's immediate superdomain -- eg between example.com. and com. -- that 
to some degree is presently addressed by language in RFC6265 section 5.3 
step 5 --- but nominally I think Eric is overall correct and this "cookie 
injection attack via superdomain of HSTS Host" isn't properly discussed in 
RFC6797 and that it would (today) be an issue for example if foo.example.com 
is a distinct entity from example.com, and example.com _is not_ a "public 
suffix". Essentially, i think there's a subtle impedance mismatch between 
HSTS's Storage Model and that of HTTP cookies per RFC6265, and it's arguably 
a spec bug in rfc6797 that it isn't explicitly called out.

Thus Barry is correct that this is treading into "domain boundary" aka 
"domain policy authority" territory <dbound <at> ietf.org> -- and thus is another 
example of why the latter work is important (several of us, along with 
Andrew Sullivan, are chipping away at it).

Also, there's a recent draft academic paper that's been mentioned on other 
lists that I am going to post a reference to on this list -- it goes into 
HSTS deployment common mistakes as well as best practices and touches on 
issues similar to this.

ah, I see Eric's proposed best practice in his reply to Yoav, and yeah, 
that's one way to address this issue, and could ostensibly be included in a 
spec update -- but the actual errata is the above-noted impedance mismatch 
between cookies' and HSTS's storage models (and also the lack of cookie's 
declaring their originating origin).

HTH,

=JeffH


Gmane