Re: [websec] Issue #53 - Clarify status of pin validation when used with private trust anchors
Yoav Nir <ynir@checkpoint.com> Thu, 22 November 2012 07:40 UTC
Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6121F8824 for <websec@ietfa.amsl.com>; Wed, 21 Nov 2012 23:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJbytCMIHJmR for <websec@ietfa.amsl.com>; Wed, 21 Nov 2012 23:40:45 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2021F872D for <websec@ietf.org>; Wed, 21 Nov 2012 23:40:44 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qAM7edmD015918; Thu, 22 Nov 2012 09:40:39 +0200
X-CheckPoint: {50ADD397-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.194]) by IL-EX10.ad.checkpoint.com ([169.254.2.194]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 09:40:39 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<ryan-ietfhasmat@sleevi.com>" <ryan-ietfhasmat@sleevi.com>
Thread-Topic: [websec] Issue #53 - Clarify status of pin validation when used with private trust anchors
Thread-Index: AQHNyDCCC7tisBFlqEKwaMuz+22tG5f043WAgABtaAA=
Date: Thu, 22 Nov 2012 07:40:38 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772101E8A8@IL-EX10.ad.checkpoint.com>
References: <4613980CFC78314ABFD7F85CC302772101E042@IL-EX10.ad.checkpoint.com> <77ae8817edac8638b9ebf63b1f9ce6fb.squirrel@webmail.dreamhost.com>
In-Reply-To: <77ae8817edac8638b9ebf63b1f9ce6fb.squirrel@webmail.dreamhost.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [91.90.139.66]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11fabee777a2e970584b3286dfb2d6df24f7db8561
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <94E82F1BE0F9FE48B6571FF11C6EF6C4@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Issue #53 - Clarify status of pin validation when used with private trust anchors
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2012 07:40:45 -0000
On Nov 22, 2012, at 2:45 AM, Ryan Sleevi <ryan-ietfhasmat@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 sending "policy=accept_private" to be safe, which seems like both > a sharp edge to find and perhaps more bytes than needed. Got me convinced. And I agree that there will be very few sites that actually use "strict", unless some auditor or PCI decide that this is a good idea. And even if they did, they'd get a lot of pushback, because this actually makes the website works in fewer places. This is not the same as mandating RC4 for fear of the BEAST. Yoav