IETF Logo Mail Archive

Re: [websec] Comments on draft-ietf-websec-key-pinning

Jeffrey Walton <noloader@gmail.com> Thu, 19 February 2015 19:38 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A051A0062 for <websec@ietfa.amsl.com>; Thu, 19 Feb 2015 11:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkpt26fxvbtJ for <websec@ietfa.amsl.com>; Thu, 19 Feb 2015 11:38:37 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCB21A0117 for <websec@ietf.org>; Thu, 19 Feb 2015 11:38:25 -0800 (PST)
Received: by iecrp18 with SMTP id rp18so2626655iec.1 for <websec@ietf.org>; Thu, 19 Feb 2015 11:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K6YzyeEDlbjSetXmakQCJaQWS+K9ZiXRBiFGOlPecNg=; b=W9xCt1JizY198CIBXQU+5JTiV7hT6/9DX2dQ7dhQ6PD4uqmS+kDItgUuvFOmeVUtW2 a3M7FjKro/bw6cpi7w8AT84tpKIGLGwPqV7HhkrX3kCxRho0wGKNCRxDjVpIbzdhBQK3 kJ7+/MIyBoujB9yqI02ZYHJMBuFIDoO7ZMXxcm/VNM6f8fSktnyb7uti5hNNUDofPzn1 m65p86X2uAy6cOpgUPrnzIVki4aCxyuIbJzlIa3LXNh+faCPtXBg0DIHv7nuKlHs42Vm ur+aud7vwq4ymFH0Eq3PMyK9fYmulYN0EIaHBeqbuyGqlQNjcMyNz0mOljb/HxB1wYZj A49g==
MIME-Version: 1.0
X-Received: by 10.42.201.78 with SMTP id ez14mr8071232icb.22.1424374704508; Thu, 19 Feb 2015 11:38:24 -0800 (PST)
Received: by 10.36.81.15 with HTTP; Thu, 19 Feb 2015 11:38:24 -0800 (PST)
In-Reply-To: <CAOe4UikDvdbcN-mekL25hdWEp22tUMYpsMFw-Wp3sW6O5TBrEg@mail.gmail.com>
References: <CAH8yC8=XEr9q8VHarucKa0rVqSPt3=oDzDRWXA3_u4rkhpZmoQ@mail.gmail.com> <CAH8yC8==Bkw_65UALEgz73djDyQFnw5m3bHY0Wav=ABvi9ORVA@mail.gmail.com> <CAOe4UikDvdbcN-mekL25hdWEp22tUMYpsMFw-Wp3sW6O5TBrEg@mail.gmail.com>
Date: Thu, 19 Feb 2015 14:38:24 -0500
Message-ID: <CAH8yC8=q3BoDU4Q=5FtnLSmH+OziLyEH6K2fhfVZcZT3XtSMaQ@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Joseph Bonneau <jbonneau@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/kQGOhFSQSCxjuM95Hue47AYCfK8>
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
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, 19 Feb 2015 19:38:38 -0000

> Ryan's previous post already covered the reasons for disabling pin
> validation for user-defined trust anchors, which still hold even though
> Superfish did their superfish thing.

That's not acceptable for two reasons. First, the user did not take an
administrative action. Second, pinning is a control we use to stop
that sort of thing.

We also don't have an audit trail because the IETF thought it was wise
for the user agents to be complicit in the cover up.

I don't believe this proposal - in its current form - will prove
effective in the canonical cases: (1) CA failure like Diginotar; and
(2) MitM attacks like Superfish. Are there other obvious cases I
missed that this control will be effective?

Jeff

On Thu, Feb 19, 2015 at 1:00 PM, Joseph Bonneau <jbonneau@gmail.com> wrote:
>
> On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>>
>> Quod erat demonstratum:
>>
>> http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/
>>
>> This proposal needs to be revisited. It has serious defects.
>
>
> Ryan's previous post already covered the reasons for disabling pin
> validation for user-defined trust anchors, which still hold even though
> Superfish did their superfish thing.
>
> If the spec did not allow this behavior, the next Superfish would probably
> just configure local UAs to launch with pinning disabled completely. I don't
> think their recklessness would somehow stop short of overriding the
> browser's pinning policy.

v2.23.0 | Report a Bug | By Email