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

Yoav Nir <ynir@checkpoint.com> Mon, 12 December 2011 15:19 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 00A5921F8B63 for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 07:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.572
X-Spam-Level:
X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 9njOEFU-f3Eb for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 07:19:05 -0800 (PST)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15CC621F8B5B for <websec@ietf.org>; Mon, 12 Dec 2011 07:19:04 -0800 (PST)
X-CheckPoint: {4EE61A11-1-1B221DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCFJ2Gw028291; Mon, 12 Dec 2011 17:19:03 +0200
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 17:19:02 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Date: Mon, 12 Dec 2011 17:19:19 +0200
Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning
Thread-Index: Acy44WCFEd1hqCPMSaaMm9HkSlnUDg==
Message-ID: <AF47F8EB-FC41-47EF-8327-4AE52E27547A@checkpoint.com>
References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org>
In-Reply-To: <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:19:06 -0000

On Dec 12, 2011, at 5:06 PM, Paul Hoffman wrote:

> 
> 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.

The rogue cert works only if it validates. So the attacker will have to have compromised the CA as well. Besides, one could argue that using a certificate without OCSP or checking the CRL is not "error-free", but that would have to be clarified.

> 
>> 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.

Agree, but it allows me to make my site safe from rogue pinning attacks now.

> 
>> 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.
>