Hill, Brad | 16 Sep 23:09 2014
Picon

Review request for a few WebAppSec specs.

BCC: public-webappsec <at> , FYI.
CC: <WebAppSec editors/chairs>

Hello IETF WebSec folks,

The WebAppSec WG over at the W3C has a few specifications in flight for which we're actively seeking
feedback. One or more of them might be interesting to you; if you have some spare time, we'd very much
appreciate your feedback:

CSP2: https://w3c.github.io/webappsec/specs/content-security-policy/
Mixed Content: https://w3c.github.io/webappsec/specs/mixedcontent/
Referrer Policy: https://w3c.github.io/webappsec/specs/referrer-policy/
Subresource Integrity: https://w3c.github.io/webappsec/specs/subresourceintegrity/

The first three are in pretty good shape both in terms of the spec text and implementations. The last (SRI)
would be more of a pre-review, but would still be helpful for us.

Thanks!

Brad Hill
Anne van Kesteren | 16 Sep 18:57 2014
Picon

HSTS and subdomains

If example.com serves up a policy with includeSubdomains. And
sub.example.com serves up a policy without includeSubdomains,
max-age=0, and redirects to http://sub.example.com.

I first visit example.com. And then I visit sub.example.com. What
happens and where is this defined?

--

-- 
https://annevankesteren.nl/

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


Gmane