[websec] Issue #53 - Clarify status of pin validation when used with private trust anchors

Yoav Nir <ynir@checkpoint.com> Wed, 21 November 2012 21:38 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 3CA4521F8472 for <websec@ietfa.amsl.com>; Wed, 21 Nov 2012 13:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.28
X-Spam-Level:
X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=-0.281, 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 EOMdX2UzmVoB for <websec@ietfa.amsl.com>; Wed, 21 Nov 2012 13:38:20 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BE8BD21F846C for <websec@ietf.org>; Wed, 21 Nov 2012 13:38:18 -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 qALLcFmY008251 for <websec@ietf.org>; Wed, 21 Nov 2012 23:38:15 +0200
X-CheckPoint: {50AD466B-5-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; Wed, 21 Nov 2012 23:38:14 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: IETF WebSec WG <websec@ietf.org>
Thread-Topic: Issue #53 - Clarify status of pin validation when used with private trust anchors
Thread-Index: AQHNyDCCC7tisBFlqEKwaMuz+22tGw==
Date: Wed, 21 Nov 2012 21:38:13 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772101E042@IL-EX10.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.66]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11bf8ec186f4f2188bdb69170021e60b572269ddd0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <650813A8C5E74040823823BE0F4F4F96@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Wed, 21 Nov 2012 21:38:21 -0000

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?

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?

Yoav