Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Wed, 06 March 2013 19:34 UTC

Return-Path: <ryan-ietfhasmat@sleevi.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 520CB21F8CBD for <websec@ietfa.amsl.com>; Wed, 6 Mar 2013 11:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
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 DfrEJvUiOAgN for <websec@ietfa.amsl.com>; Wed, 6 Mar 2013 11:34:18 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4111E80C5 for <websec@ietf.org>; Wed, 6 Mar 2013 11:34:18 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E0DCE94075; Wed, 6 Mar 2013 11:34: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=d4bWOvKAWeMQ1SuSW7FKSimC1oI=; b=naDtf3HS50XYPR6+0 sl49vGCSCrSRhl4OMZEtlOwp5FCEBmZiXJe1iSM5Vm5fRxh89q3sbmGjz9hZQKKj jAigvSMXHY0czUFW7g+/s7purtHm1RzkidN6iYqZ8HwG/EDAtItHZNWlWlpAm7PV cRG9wGJWVExHfyC9Q6/KGLApWQ=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 9CC849406E; Wed, 6 Mar 2013 11:34:17 -0800 (PST)
Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 6 Mar 2013 11:34:17 -0800
Message-ID: <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com>
In-Reply-To: <CA+cU71nCoCOSL+qpB3OkvjBEHYxOBA40-DLdHrjNNUxJ1M_7=w@mail.gmail.com>
References: <b6009964af0dae16c45619eb94c0f0e9.squirrel@webmail.dreamhost.com> <CA+cU71nCoCOSL+qpB3OkvjBEHYxOBA40-DLdHrjNNUxJ1M_7=w@mail.gmail.com>
Date: Wed, 06 Mar 2013 11:34:17 -0800
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: Tom Ritter <tom@ritter.vg>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org
Subject: Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Mar 2013 19:34:22 -0000

On Tue, March 5, 2013 6:55 pm, Tom Ritter wrote:
>  On 4 March 2013 19:57, Ryan Sleevi <ryan-ietfhasmat@sleevi.com> wrote:
> > The authors belief is that the issues that arise from either
> > implementations are artifacts of the implementation and distribution of
> > preloaded pins, rather than an issue intrinsic to this specification.
> > That
> > is, the "correct" answer is that the preloaded pin list should be
> > updated
> > for Site 1 - however that information is distributed between the site
> > operator and the creator of the preloaded pin list.
> >
> > Are there concerns with this interpretation, or can we close out Issue
> > 55?
>
>  I guess I'm just confused.  I agree it's rife for implementation
>  differences, but I either
>  A) Incorrectly parse this as punting on guidance that would (try to)
>  achieve parity across implementations and prevent yet another thing
>  that webmasters need to understand when requesting preloading in
>  multiple browsers
>  b) Correctly parse it as such, but don't understand why you would punt
>  on expressing a standard behavior instead.
>
>  -tom
>

I think the real answer should be that preloading shouldn't be part of the
spec, as it really is an implementation-specific behaviour. Certainly,
it's based on our experiences in Chrome/Chromium, and it does provide an
additional measure of security for the initial connection, but it doesn't
really tie into the semantics of the header at all.

Different applications - including such like Firefox - have already
expressed interest in pursuing different schemes for preloading and the
maintenance of such lists. Certainly, we've looked at alternatives
ourselves. Our thinking is that we should avoid baking such behaviours
into a spec, and instead focus solely on the header and observation
aspects.

Unlike the header - which is presumably provided to all user agents and
uniform implementation expected - preloading is (at least, today) about a
relationship between the site operator and individual user agents, so
there's already a communication channel. If other implementations pursue
different schemes - eg: such as crawling and noting pins - then they may
have vastly different needs/requirements, but the overall semantics of the
header itself remains the same.