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

Tom Ritter <tom@ritter.vg> Thu, 07 March 2013 02:50 UTC

Return-Path: <tom@ritter.vg>
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 68BF011E80F0 for <websec@ietfa.amsl.com>; Wed, 6 Mar 2013 18:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.758
X-Spam-Level:
X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 27eKbbK4ZGKQ for <websec@ietfa.amsl.com>; Wed, 6 Mar 2013 18:50:03 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01D11E80E9 for <websec@ietf.org>; Wed, 6 Mar 2013 18:50:03 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id k1so5201917vck.38 for <websec@ietf.org>; Wed, 06 Mar 2013 18:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=mIBmUmv0dhob2r+sMikCHlDV0LTy+Dtj8lJsCu+Ei1OOAOY7zwPqmk5fdKastWnX+e VH29kkYU743iFO8c6ubYG/ddnTJEktOYumKhE9WnA9onR1DAiFABo2eON8cq5Qnv9c/E oU/I/O+MVmCvLkkYZNbzph94/TAYevBrM+oA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=ZmoZPfgGiEkr6aV5J4txbvXXc+wCUFSo1fhy4laYzuvbOaS7BHByNh35nFnJtiy5kE pT3zANmSe+ITIiW9stXCxQUdNGCpzqDFyDKIJUJFE7gwCEftbBzn9ecIVFVXBOufFYKW zAihIBWgbYclmYWHWcDSz7WcZql+6nqk1/jjIH1hjJAL05/jZ9MpOyILBbMwzJNOJl+u 7JIPif2/zUtxWpEad66S2j5VSUljFtm5vOPVqOH9bhNEImFW8/VsuknKYATTjfTDMsVS WmOdDN0xkoxrl8UqwpZt+wQUfiD+xubzYDSbkV0mm3NIroPj9GxtoJF4/96F/Znxe/Y9 aavQ==
X-Received: by 10.58.46.134 with SMTP id v6mr12676910vem.45.1362624602766; Wed, 06 Mar 2013 18:50:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.182.169 with HTTP; Wed, 6 Mar 2013 18:49:42 -0800 (PST)
In-Reply-To: <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com>
References: <b6009964af0dae16c45619eb94c0f0e9.squirrel@webmail.dreamhost.com> <CA+cU71nCoCOSL+qpB3OkvjBEHYxOBA40-DLdHrjNNUxJ1M_7=w@mail.gmail.com> <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 6 Mar 2013 21:49:42 -0500
Message-ID: <CA+cU71nOn5bXGczKMMZND6bk6bQTwq0NMk2sSTsp9D5Y8+ND2Q@mail.gmail.com>
To: ryan-ietfhasmat@sleevi.com
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlmJm2ApiED3Fh5Gb05AWIY/KC40r8GyX94EyA5pEODuhbnX1qHZ3KOUyIgHq+Q5lY1znD1
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
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, 07 Mar 2013 02:50:04 -0000

On 6 March 2013 14:34, Ryan Sleevi <ryan-ietfhasmat@sleevi.com> wrote:
> 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.


Fair enough. I hope a browser will be willing to fiddle with their
preloading mechanism if it's found to cause pain, and I hope any site
owner would not put in preloaded pins with a browser that couldn't
amend them easily.

I'll only mention for consideration rewording the line to say "the
newest information available for the host":

UAs MUST use the newest information available for the host -- built-in
or set via Valid
   Pinning Header -- when performing Pin Validation.

This may guide things better without being overly restrictive.

-tom