Re: [websec] A few comments on draft-ietf-websec-key-pinning

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 12 December 2011 15:06 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 916AA21F8B6D for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 07:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level:
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp34WsTdcUx9 for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 07:06:22 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1382D21F8B6C for <websec@ietf.org>; Mon, 12 Dec 2011 07:06:22 -0800 (PST)
Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBCF6BEH028281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Dec 2011 08:06:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com>
Date: Mon, 12 Dec 2011 07:06:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org>
References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning
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: Mon, 12 Dec 2011 15:06:22 -0000

On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote:

> Section 2.3 does say that pins must only be noted if they come over an error-free HTTPS connection, where the chain contains the pinned SPKI. So the MITM would have to be able to take over the DNS (at least for a while) as in the attack described by David on 11-Dec.

I don't agree that the MITM must control the DNS for this attack to work. As long as the MITM can intercept the TLS handshake, and the client isn't doing OCSP (or the MITM intercepts that too), using a rogue cert works; thus the rogue pinning works as well.

> Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds"

That still doesn't deal with the site that hears about the pinning header after the MITM does.

> A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256".

Good point, and one that might be made on the SAAG list as well.

--Paul Hoffman