On Nov 22, 2012, at 2:45 AM, Ryan Sleevi ryan-ietfhas...@sleevi.com wrote:
On Wed, November 21, 2012 1:38 pm, Yoav Nir wrote:
Hi
During the meeting in Atlanta I said that saying that that pin validation
is disabled when the cert chains to a private trust anchor would not go
over well, because it's disabling a security feature in the presence of an
attack. I still think so, but I think we can raise less red flags if we
just describe what the issue is - that there is a TLS proxy.
I don't have suggested text, at least yet, but here's how I think the
issue can be addressed. Keep in mind that we're not writing a design for
any particular browser.
===
On some networks, mostly corporate networks, there are TLS proxies,
transparent proxies that sign certificates on behalf of visited web sites
as described in [ref]. When a UA gets into such a network, the certificate
presented in the TLS handshake will not be consistent with the UA's
previously stored pins.
It is up to the UA to decide whether such a TLS proxy is acceptable or
not. If it is acceptable, then pinning should be disabled, and the UA
should not follow the mandates in section 2.4 of this document. Ideally,
such proxies, or their associated trust anchors would be specially marked
as trusted for this purpose. If the UA does not allow for such a
configuration, a heuristic MAY be used to determine what trust anchors are
used for a legitimate TLS proxy. One such heuristic, is that all trust
anchors that are not part of the stock trust anchor store that comes with
the UA or the operating system, but that are in the trust anchor store
(implying that they have been added by the user) are acceptable for TLS
proxies.
===
I think this defuses the issue. What do others think?
The wording suggests that it's primarily a network layer 'attacker', which
somehow raises the spectre of RFC 1984 (unfairly, I think), but we also
see TLS proxies that are entirely local to clients' machines - for
example, Antivirus Software that installs a Winsock LSP.
OK, but clients that share a machine with software like that can never ever
verify pins. I don't think we really need to talk about them.
I'm still working with Chris Palmer to find suitable language to propose
on this, but we've been looking at ways to define this processing in terms
of client policy that may supercede or disregard the the Pinning
Metadata for a Known Pinned Host, to be incorporated into Section 2.4.
(Validating Pinned Connections)
Looking forward to seeing this.
One other suggestion that was brought up in Atlanta, was to have the
server specify a policy about private trust anchors in the Public-Key-Pins
header, something like:
Public-Key-Pins: max-age=500; policy=strict;
pin-sha1=4n972HfV354KP560yw4uqe/baXc=;
pin-sha1=IvGeLsbqzPxdI0b0wuj2xVTdXgc=
Public-Key-Pins: max-age=31536000; policy=accept_private;
pin-sha1=4n972HfV354KP560yw4uqe/baXc=;
pin-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=
In case of policy=strict, the UA will not accept any handshake that
disagrees with stored pins. This might be preferred by some servers, that
are willing to accept not being accessible from all networks for the
benefit of preventing MitM attacks. What do others think about this idea?
Given HPKP's shared history with HSTS, and as discussed during Atlanta,
one of the things we were looking at was ensuring the ABNF grammar was
consistent with the grammar that was decided for HSTS. In particular, the
ABNF grammar should NOT specify all of individual tokens, but instead
define the set of directives, to allow new directives to be added.
This ABNF looks as such:
Public-Key-Pins = Public-Key-Pins : [ directive ] *( ; [ 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
With the above grammar, and given that HPKP's threat model is primarily
motivated by allowing site operators to defend against certificate
misissuance from CAs trusted by the client, we're proposing that 'strict'
be added (as a simple-directive). The absence of 'strict' implies that the
UA is permitted to allow client local policy to override the directive,
while the presence of 'strict' implies that the header should be
interpreted exactly as it is supplied.
The reasoning to making the default open, rather than closed, is that we
anticipate that 'strict' is not the primary or default mode that sites
intend to operate in (since client policy is a known-unknown from the
perspective of site operators), so this is primarily an ease-of-use
feature.
I think your proposal to use a policy directive with a set of known value
strings may also work, but my fear is that it would just end up with most
servers
