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

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Fri, 20 February 2015 03:42 UTC

Return-Path: <ryan-ietfhasmat@sleevi.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 4D1D91A1EF6 for <websec@ietfa.amsl.com>; Thu, 19 Feb 2015 19:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 51-3vBtXSC9M for <websec@ietfa.amsl.com>; Thu, 19 Feb 2015 19:42:19 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFB71A1BE9 for <websec@ietf.org>; Thu, 19 Feb 2015 19:42:18 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id D4099674058; Thu, 19 Feb 2015 19:42:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=bcMZDQ8O6kdiZfMP98lKyXZ5sPE=; b=mjmMGrI6KIVj9aTz7 2wqUNJLh3Ch0i89xxp+mrs38Ada+QzbjXfg9K/NMmq1GW6/KKvB2t2vhDJ0G2hd+ wP3ieJGN5Ur5lw7yaxOnx59m30WP54hDkv3/xl6VmFSO0qq768bGrCIvdBWnachl k/D9I3crTjrwJ767d+4fzVk6LA=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id AC416674057; Thu, 19 Feb 2015 19:42:17 -0800 (PST)
Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 19 Feb 2015 19:42:17 -0800
Message-ID: <5bd1e5f598ebde476bfdefa8993b8dc1.squirrel@webmail.dreamhost.com>
In-Reply-To: <CAH8yC8=q3BoDU4Q=5FtnLSmH+OziLyEH6K2fhfVZcZT3XtSMaQ@mail.gmail.com>
References: <CAH8yC8=XEr9q8VHarucKa0rVqSPt3=oDzDRWXA3_u4rkhpZmoQ@mail.gmail.com> <CAH8yC8==Bkw_65UALEgz73djDyQFnw5m3bHY0Wav=ABvi9ORVA@mail.gmail.com> <CAOe4UikDvdbcN-mekL25hdWEp22tUMYpsMFw-Wp3sW6O5TBrEg@mail.gmail.com> <CAH8yC8=q3BoDU4Q=5FtnLSmH+OziLyEH6K2fhfVZcZT3XtSMaQ@mail.gmail.com>
Date: Thu, 19 Feb 2015 19:42:17 -0800
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: noloader@gmail.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/AlqGHrbJmh5HneyAYWSD9G7b-uA>
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: ryan-ietfhasmat@sleevi.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: Fri, 20 Feb 2015 03:42:20 -0000

On Thu, February 19, 2015 11:38 am, Jeffrey Walton wrote:
>  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

You're factually wrong in cases like (1), and woefully misguided in cases
like (2) if you believe _any_ software, on a general purpose operating
system with 1-layer security principals (such as Windows and OS X), can
defend against a program with same-or-higher privileges.

That's like complaining a program with root access can interfere with your
usermode application. Well, yes, that's exactly correct, that's how it's
supposed to work.

If you can conceive a model where a super-user process would not be able
to circumvent, then congrats, you've solved one of the most vexatious
problems in computer security, and I know a dozen of anti-virus and
anti-malware companies that will let you name your price if only you share
your solution with them.

Consider the following ways that an application like Superfish could have
dealt with this (courtesy of a colleague far brighter than I)
- PTRACE_POKETEXT a code modification at runtime
- LD_PRELOAD a shim that intercepts strcmp and returns false for
"Strict-Transport-Security"
- Patch GTK+ (or equiv) so that the lock icon always appears on the omnibox
- Rebuild a version of the browser with the code to disable such pinning
commented out.

There is no sane world in which anything in the HPKP spec can or should
deal with this. It's doubly true and hopefully self-evident that "raising
the bar" is not at all an acceptable, or even reasonable, justification.
Malicious actors have every reason to escalate to more nefarious means
(whether for profit or interception), while legitimate actors get shut out
or, equally, burrow further into internals and cause worse experiences for
everyone.

I understand that you disagree. But you're also wrong if you think HPKP
can or should have dealt with this.

Best regards,
Ryan