Subject: Re: [websec] HPKP: The strict directive and TLS proxies

From: Yoav Nir <[email-masked]>
Date: Sun, 1 Dec 2013 19:49:19 +0200

On 29/11/13 10:24 PM, Trevor Perrin wrote:
> On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir <[email-masked]> wrote:
>> To summarize, although there has been much discussion since version -06,
>> most of it did not result in massive changes to the document, so IMO we
>> don't need another WGLC.
>
>   * Weren't we going to discuss the relationship of preloaded to
> dynamic pins?  See email [1].
>
>   * The rationale in thread [2] for "strict" seems different from the
> rationale in previous list discussions [3].  Ryan now argues that
> "strict" is not needed.  I think that's worth considering.
>
>   * I had feedback on an earlier draft which is still relevant [4], see below.
>
> [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html
> [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html
> [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html
>
[hat off]
Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot 
down and easily convinced me. The "strict" directive has come up in 
discussion at httpbis as well. There's all kinds of talk about adding a 
"trusted proxy" (a proxy that can see the plaintext). These are used 
today by performing a MitM attack on the client (with the grudging 
cooperation of the user or the administrator of her computer. The server 
does not have any way to ask the browser to not cooperate with the 
MitM.  A "strict" PKP is one great way to convey that policy, and I 
don't think we should give up on it.  This is especially useful now that 
a lot of the content sites (Facebook, Google, Twitter) are becoming 
HTTPS-only, and pretty much every firewall around can now do the MitM 
thing.

Unless there's some good reasons to leave this off, I think we should 
leave this one in the spec just as it is. Unless we're afraid people 
might use it ([4]).
[/hat off]

Yoav

[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1461.html

---

From: Yoav Nir <[email-masked]>
Date: Sun, 1 Dec 2013 19:53:41 +0200

[hat off]

Yoav

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 01 Dec 2013 17:58:07 +0000

Am 01.12.13 17:49, schrieb Yoav Nir:
> pretty much every firewall around can now do the MitM thing

For those cases where the system administrator in an enterprise network 
installs a fake cert in your trust anchor store. For BYOD and other 
cases this is not possible since it would be indistingushable from an 
attack*.

Ciao
Hannes

*: Some people may even argue that the practices of some enterprise 
networks are attacks but luckily there are also other companies around.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 1 Dec 2013 23:02:23 +0200

On 1/12/13 7:58 PM, Hannes Tschofenig wrote:
> For those cases where the system administrator in an enterprise 
> network installs a fake cert in your trust anchor store. For BYOD and 
> other cases this is not possible since it would be indistingushable 
> from an attack*.
When you bring your own device (like I do), you get tired of clicking 
through red screens, so you finally download the MitM CA cert, and 
install it yourself in your trust anchor store. You do it anyway if 
you've decided to use Firefox.

The point is, that whether you do or you don't, the server has no say in 
the matter without the "strict" directive.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 1 Dec 2013 16:25:02 -0800

On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir <[email-masked]> wrote:
> Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot down
> and easily convinced me. The "strict" directive has come up in discussion at
> httpbis as well. There's all kinds of talk about adding a "trusted proxy" (a
> proxy that can see the plaintext). These are used today by performing a MitM
> attack on the client (with the grudging cooperation of the user or the
> administrator of her computer. The server does not have any way to ask the
> browser to not cooperate with the MitM.  A "strict" PKP is one great way to
> convey that policy

The browser has already decided to cooperate with the MITM.  I side
with Chris and Ryan: it's pointless for the site to try to win a
policy arms race here.

The question remains whether "strict" is necessary for the "pinning to
local trust anchor" case.  Ryan argues that it's not, and describes a
way for the browser to handle this without "strict":

http://www.ietf.org/mail-archive/web/websec/current/msg01947.htm

That proposal makes sense to me, and avoids the complexity of an
additional directive.  So I support removing "strict", and adding text
for this "pinning to local trust anchor" case.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Dec 2013 07:09:53 +0200

On 2/12/13 2:25 AM, Trevor Perrin wrote:
> http://www.ietf.org/mail-archive/web/websec/current/msg01947.html
>
The proposal there is for pins that chain to a well-known CA can be 
overridden, but pins that chain to local CAs cannot. This means that 
public sites, such as banks, social media and corporate portals (one 
type of "SSL VPN") cannot opt out of this local policy override.

With vendor hat on, we have been asked by customers whether we could 
prevent traffic to SSL VPNs (which we provide) from being decrypted. 
Currently, the only options we can give them are to deploy client 
certificates or to use IPsec VPNs. The above proposal adds one other way 
- to deploy a corporate CA. All three defeat the purpose of SSL VPNs 
that is that they can be used from pretty much any device. A "strict" 
directive and enforcing browser version (yes, I know it can be spoofed - 
none of this is secure against a malicious client) can get us close enough.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 1 Dec 2013 22:10:26 -0800

On Sun, Dec 1, 2013 at 9:09 PM, Yoav Nir <[email-masked]> wrote:
> overridden, but pins that chain to local CAs cannot. This means that public
> sites, such as banks, social media and corporate portals (one type of "SSL
> VPN") cannot opt out of this local policy override.
>
> With vendor hat on, we have been asked by customers whether we could prevent
> traffic to SSL VPNs (which we provide) from being decrypted. Currently, the
> only options we can give them are to deploy client certificates or to use
> IPsec VPNs. The above proposal adds one other way - to deploy a corporate
> CA. All three defeat the purpose of SSL VPNs that is that they can be used
> from pretty much any device. A "strict" directive and enforcing browser
> version (yes, I know it can be spoofed - none of this is secure against a
> malicious client) can get us close enough.

It's unclear what you're describing.

Is it something like this? -
 - Company A provides an SSL VPN to its employees, but is unwilling to
customize the user's software (e.g. install a trust root)
 - Company B requires everyone working onsite to send all traffic
through a MITM proxy, and *is* willing to customize the user's
software (e.g. install a trust root)
 - An employee of Company A is working onsite at Company B, using her
company A laptop, yet subject to B's IT policies (which doesn't make
sense, but let's soldier on...)
 - Company A would like to prevent the user from accessing A's SSL VPN
through B's MITM proxy

Is this where you think "strict" is useful?  Company A would assert a
"strict" pin for its SSL VPN?

I think it's useless here.  If "strict" was in the spec, many sites
would undoubtedly enable it, causing these sites to (hypothetically)
not to work through B's MITM.  But B would "fix" this by configuring
user browsers to ignore strictness (or even worse, requiring users to
disable pinning, or use a browser without it).

You can't win a policy fight with someone who controls the machine.
It's pointless to try.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Dec 2013 08:50:17 +0200

> customize the user's software (e.g. install a trust root)

Yes. Maybe this is because the employee is using some weird device like a Mac, or a Windows Phone, or a box running Ubuntu - things the IT department has no idea how to handle. In other cases, we've seen SSL VPNs deployed to customers or partners.

> software (e.g. install a trust root)

Either that, or they can keep clicking through warning screens.

> sense, but let's soldier on…)

Sure it makes sense. The transparent proxy goes with the Wifi.

> - Company A would like to prevent the user from accessing A's SSL VPN

*Any* MitM proxy.

> disable pinning, or use a browser without it).

I don't think many would enable it. I don't think even banks would, and I'm pretty sure social media, and web-based mail wouldn't. It's a niche of web sites that would enable it.

> You can't win a policy fight with someone who controls the machine.

Agreed. But the use case is against someone who does not control the machine.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 2 Dec 2013 00:04:14 -0800

> Either that, or they can keep clicking through warning screens.

Completely different case - in that case, the browser is going to be
screaming murder on *every* HTTPS access, and "strict" makes no
difference.

> Sure it makes sense. The transparent proxy goes with the Wifi.

What doesn't make sense is that company A's VPN is being accessed
through machines under the IT control of company B, yet A is trying to
enforce its IT policy on these machines.

> I don't think many would enable it. I don't think even banks would, and I'm pretty sure social media, and web-based mail wouldn't. It's a niche of web sites that would enable it.

As soon as one major website chooses to use this then MITM products
break.  As soon as those products break, they'll be "fixed" by
instructing customers how to bypass strict pinning (or all of
pinning).

At that point, "strict" becomes worthless spec clutter.

> Agreed. But the use case is against someone who does not control the machine.

No, it's about trying to override "local client policy".  Someone who
controls that policy controls the machine.  It's silly to think an
HTTP header is going to override that control.

Trevor

---

From: Brian Smith <[email-masked]>
Date: Mon, 2 Dec 2013 00:09:40 -0800

Ryan Sleevi <[email-masked]> wrote:
> Trevor Perrin wrote:
>>  Ryan Sleevi <[email-masked]> wrote:
>> > Trevor Perrin wrote:
>> >>   * Section 2.6 mandates "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".  HSTS allows the server to
>> >>  specify this, so it seems unnecessary and inflexible to mandate it
>> >>  here.  It's also unclear whether a "report-only" pin counts as a
>> >>  "Pinned Host".
>> >
>> > This is a feature, not a bug.
>> >
>> > PKP is useful without mandating HSTS. However, the security advantages
>> > of PKP can be undermined, much the way HSTS's can, if the UA allows
>> > users bypass.
>>
>>  I think it's a mistake to mandate UI here.  "Users clicking through
>>  legitimate security errors" is one risk.  "Users being denied access
>>  to legitimate sites due to pinning failures" is another.
>>
>>  It's hard to know how to balance these.  We should allow UAs latitude.
>>   I suggest changing the text from MUST to SHOULD, at minimum.
>
> Thanks for your feedback. I'd like to hear from others in the WG if that
> view is shared. To this point, we haven't heard any concerns about the
> MUST, and the security properties are seemingly well understood.
>
> Certainly, no UA vendor has asked or proposed such latitude. But then
> again, we're all individuals here. I do fail to understand your
> distinction between "legitimate security errors" and "pinning failures". I
> would certainly count the latter amongst the former, and so I fail to see
> how the risks differ, beyond being a superset/subset.

I think it would be difficult for any UA to commit to implement this
as written. For example, False Start intolerance is an error, but
fallback when False Start intolerance is detected doesn't seem like
something that should be prevented by pinning. (Especially if such
intolerance can only be detected sporadically.)

I suggest that the specific types of errors that UAs MUST terminate
the connection for be enumerated (expired certificate, revoked
certificate, receipt of any fatal alert in the TLS 1.0, TLS 1.1,
and/or TLS 1.2 specifications, etc.). Then, leave the rest as SHOULD.
Or, just make it SHOULD.

>> >>   * Why is SHA1 supported?  If the reason is size, why not remove it
>> >>  but allow the server to pin to a truncated hash (e.g. pin to the first
>> >>  16 or 20 bytes of SHA256)

> In short, I don't feel like it's a compelling reason not to include SHA-1
> at this time (but am happy to see if the WG, ADs, or CFRG feel otherwise),
> but I would definitely have concern over the complexity of some truncation
> schemes. Example concerns with the proposal include: Is it arbitrary or is
> it fixed? If it's fixed, is the criteria size of the hash? Speed of the
> hash? Some other criteria?

I agree that SHA1 doesn't need to be supported and shouldn't be a
MUST-support feature. Let's be nice to our future selves and save them
the pain of having to decide what to do about SHA1 in 2017 or
whenever. In general, I think that new standards at IETF should avoid
making SHA-1 mandatory when there are no legacy compatibility concerns
to deal with. I also agree that the complexity of specifying a
truncation scheme is concerning, and I would avoid doing anything with
truncation. If the examples in the draft are anything to go by, the
difference in length of a SHA256 hash vs a SHA1 hash is not a huge
concern, relative to the verbosity.

> Firefox, which has supported HSTS and is working on (shipping?) HPKP
> support, is likewise on a similar update trajectory and a similar
> situation where users and sites face much more pressing concerns than
> HPKP.

Firefox isn't shipping any HPKP implementation, though we are
interested in shipping some implementation key pinning, and we've done
some incomplete work on an implementation of HPKP. Because we are (I
am very) concerned about what a footgun HPKP could be, our rollout of
an implementation is likely to be very conservative. For example, I
doubt that we would support the "strict" directive initially, and I
would not be surprised if we never supporting it. (I definitely
support the removal of "strict" from this version of the spec.)

> I would think that it would be much better addressed that, as we progress
> through WGLC, IF we find we need to make backwards incompatible changes,
> we can assess the risks then, rather than act on hypothetical concerns in
> the present.

This is a draft that has three authors, all from Google, and the only
major UA implementation (AFAICT) is also Google-authored. Without a
second, independent implementation, it will be very difficult to
determine which changes need to be made to the draft spec. I think a
good litmus test for determining when HPKP may be suitable to advance
would be having https://www.google.com and other major websites send a
non-report-only HPKP header to UAs that are not based on Chromium. See
[1] for some evidence of why I think that is likely to be quite a ways
off.

[1] https://groups.google.com/d/msg/mozilla.dev.security/Cfi30mFNxd4/TMmkI2nmWlwJ

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Brian Smith <[email-masked]>
Date: Mon, 2 Dec 2013 00:23:55 -0800

On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir <[email-masked]> wrote:
> proxy that can see the plaintext).

How to help end-users deal with "trusted proxies" and how to
differentiate, if at all, benign MitMs from malicious ones, are issues
for which there is no widespread consensus amongst UA vendors.

When Firefox first started out, the fact that Firefox didn't use the
system's enterprise, sysadmin-enforced networking and trust settings
was considered a major feature by many Firefox users, and many Firefox
users still see it that way. I understand the idea that the owner of
the computer and/or the network (i.e. often the end-user's employer)
has some rights regarding how their property is used. However, many
people at Mozilla, myself included, think that ultimately the rights
of the end-user trump the rights of the property owner, though we
acknowledge that an adversarial property owner is often a very
difficult attacker for the end-user to thwart. How we ensure that both
the rights of the property owner and the rights of the end user (when
different) are met is still very much an open issue.

At least until there is a strong consensus regarding trusted proxies,
I don't think specifications like HPKP should add features to
differentiate benign MitM from malicious ones. In the case of HPKP,
the important thing is that the specification gives UAs enough
flexibility to decide how to deal with this on their own.

Ultimately, if the spec includes "strict," UAs are only going to
implement whatever mandated behavior is specified for "strict" if it
makes sense for their constituents, regardless of MUST or SHOULD. IMO,
that is a very good indication that, if "strict" survives at all, then
it should not have any MUST-level requirements for its processing.

Cheers,
Brian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Dec 2013 19:29:40 +0200

Hi

It seems like I'm the only one left who likes the "strict" directive, 
and I don't even like it much, except as a stop-gap measure until we can 
get proper proxy visibility (discussed in httpbis)

So let's make this a consensus call. If anyone (other than me) feels 
that "strict" is useful, please speak up now. Let's make it three options:

  A. Keep "strict", Explanation required
  B. Drop "strict" - not interested in local policy
  C. Drop "strict", and adopt the rule that local policy can override a 
regular CA pin, but not a local CA pin.

I think if we drop "strict", the choice between B and C will ultimately 
fall to the UA, because while Chrome might ship with a list of 
"standard" root CAs, wget does not.  But we should still make a 
recommendation.

Please send your preferences by Wednesday, December 11th.

Thanks

Yoav
[with chair hat on]

---

From: Chris Palmer <[email-masked]>
Date: Mon, 2 Dec 2013 16:24:17 -0800

Hi all,

Thanks for the discussion. We are going to roll another version of the
draft to clarify the confusing things. Also, my semi-off-the-cuff
thoughts on some of the issues:

Strict: I support what Yoav calls option (B): Drop "strict" - not
interested in local policy. (It has only been a source of confusion.
Let's keep things simple.)

SHA-1: Let's just get rid of it. SHA-256 only; MUST implement; no
truncation. (Maximum simplicity.)

Non-overridable failure mode on pin validation failure: To make HPKP
less of a footgun, I support saying that UAs SHOULD disallow user
override, or SHOULD provide some way of telling the user that pin
validation failure happened. But no longer MUST.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Dec 2013 00:52:06 +0200

On 3/12/13 10:43 PM, Tobias Gondrom wrote:
> regarding: SHA-1/SHA-256: please consider that we should have hash
> agility whenever possible. There will be SHA-3 and future ones....
>
>
Hi Tobias.

I agree with Chris that we should not specify weak algorithms in new 
specs. If we had a bunch of deployed HPKP headers with SHA-1, that would 
be different.

Having just SHA2-256 as MTI is fine, while leaving the door open for 
other algorithms. SHA2-384 and SHA2-512 and even SHA2-512/256 are pretty 
easy.

SHA-3 is different, because for efficiency, NIST intends to use 
different tuning parameters for different uses. So we might end up with 
one SHA3-256 for MACs in TLS and IPsec, and a totally different SHA3-256 
in certificate signatures, and yet a third one used for HASH-DRBG. That 
means you can't just label something "pin-sha3-256" and expect all 
implementations to inter-operate. You'd need to write an RFC "The SHA-3 
algorithm and its use in key pinning", where you'd specify the 
parameters for SHA3 in this context.

But really, SHA2-256 is an excellent MTI - it performs OK, it's 
considered secure against second pre-image, and there are no current 
indications that compromise is coming.

If somebody wants to later do this, they can create the directive 
registry then.

Yoav

---

From: Joseph Bonneau <[email-masked]>
Date: Tue, 3 Dec 2013 16:26:51 -0800

> SHA-3 is different, because for efficiency, NIST intends to use different
> tuning parameters for different uses. So we might end up with one SHA3-256
> for MACs in TLS and IPsec, and a totally different SHA3-256 in certificate
> signatures, and yet a third one used for HASH-DRBG. That means you can't
> just label something "pin-sha3-256" and expect all implementations to
> inter-operate. You'd need to write an RFC "The SHA-3 algorithm and its use
> in key pinning", where you'd specify the parameters for SHA3 in this
> context.
>

This discussion is premature of course, but there will certainly be
standard forms of SHA3 with short standard names hiding all of the current
discussion of output sizes and capacities that are currently being
discussed for the final SHA-3 spec. There will be some string like
SHA3-256-X which everybody in the world will agree on the meaning of, we
just don't know what yet.

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 10 Dec 2013 19:19:31 +0000

Hello,
re-send, as I just received an error message from the
websec-mailing-list mail-server on not delivering this email on Dec-3. 
Best regards, Tobias

-------- Original Message --------
Subject: 	Re: [websec] HPKP: The strict directive and TLS proxies
Date: 	Tue, 03 Dec 2013 20:43:49 +0000
From: 	Tobias Gondrom <[email-masked]>
To: 	[email-masked], [email-masked]
CC: 	[email-masked]

Hi Chris,

<hat=WG chair>
Yes, please roll the updates into a new version and post it as soon as
possible.
Please remember version-numbers are cheap, so rather update often.
Plus, I would really like to give the doc in its final state another
good read before we go to IESG.
</hat>

Best regards, Tobias

On 03/12/13 00:24, Chris Palmer wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec