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.
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)
>
> 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 sending "policy=accept_private" to be safe, which seems like both
a sharp edge to find and perhaps more bytes than needed.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
