Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

Chris Palmer <palmer@google.com> Fri, 19 October 2012 20:38 UTC

Return-Path: <palmer@google.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 1296221F87E2 for <websec@ietfa.amsl.com>; Fri, 19 Oct 2012 13:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7zK-V1qcsfi for <websec@ietfa.amsl.com>; Fri, 19 Oct 2012 13:38:36 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA37F21F87DF for <websec@ietf.org>; Fri, 19 Oct 2012 13:38:35 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so686461lbo.31 for <websec@ietf.org>; Fri, 19 Oct 2012 13:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=senNXHtjzJo7LySw84oIqLLdhfYlatCr2+OkPO8JcHE=; b=dNTpPBZyWluWh2Vf+p6vN/RwN5Qt05edeJsEEvCv9QLh08GN4cH9qfMrZhTLLF53O2 0HtKqrEcyJf++p4JiB/VhR0Q5bIhYeFRZhACGClSABLndQl+YaZ5YkiyXEpjS0/X+fyA Ylvw9vG7UycqXPkPrQjLZCKZ54HJhdwPdh9e1iP0YT5F0NZsa2HZ9VtmiNQNteH08cf5 mruoyHHkl4SeXMXr1+5hPy1iBw8AxgJ3CasuWFiYTnH5mZq5qDhkD0ZyWGPbNIHPJOqR uWHQMaeB5o0Px6nJTnzPmwIn/bKdbIgU1PrdECybLwHiC+NTLlHYaRtedm3adq7qnLkt w05Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=senNXHtjzJo7LySw84oIqLLdhfYlatCr2+OkPO8JcHE=; b=HYMSx5ZsM+pdYmyqsyaGKGrVK/dimyd967L+1x4gYTVpgHEnB0QLvrY/586hX623os zFzq3CMJV3Z1gRt4l0fIvzxkCf3cpkMrCQXOo8oqNfT5QKg/3BZVVxccDJed/rlCHlGB NFNB6CTEZxftWU6DDQDoLqEdBSoQ1K147T3SEIjhXGxittjpCzYDg++xapisxkM47JPz OTwhKHhrgGIwy5SRLr3nEeK96VAPLZHX8fqH+iyBl/tQwXz8ZgqkE0nMVtwM6oqO1Cko JNwKAuekX6+W8s1vGqdhmy9ocaHZR0+J7Bgr3YC46C1/yIl62nwjjMSoTVyNY3IeEiJl MJRg==
MIME-Version: 1.0
Received: by 10.152.105.68 with SMTP id gk4mr2034310lab.48.1350679114618; Fri, 19 Oct 2012 13:38:34 -0700 (PDT)
Received: by 10.112.39.226 with HTTP; Fri, 19 Oct 2012 13:38:34 -0700 (PDT)
In-Reply-To: <CA+cU71mnpctpRG-1BC7mGm=PZ0q7f0JWTwZnr3zY8diJ7Aa=VA@mail.gmail.com>
References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <CAOuvq219yJ1P1STBM-AkP7aLNP1W_U8WYp2v-8x1kzXuS_VT6A@mail.gmail.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> <CA+cU71kDB19HTgJ0AiH42ErLuRLGJDavqm3boV-Hifyjjy4TgQ@mail.gmail.com> <CAOuvq21JyyRYoDnn7BFE+v=+DxKfGOmr-rE+FO67-fVwJXQJ=Q@mail.gmail.com> <CA+cU71mnpctpRG-1BC7mGm=PZ0q7f0JWTwZnr3zY8diJ7Aa=VA@mail.gmail.com>
Date: Fri, 19 Oct 2012 13:38:34 -0700
Message-ID: <CAOuvq23ChmW4xcnLnpOgasS4oZ9+gZMUNo1Yefhp3OMsb0dmZg@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmXuf4/kTJxXbT2/FkH8DaBxDNhJxn5BA/GHija+ef1CQ0l8KD35J/aXpL32pD1CsrFvq6P/4rgJK8FbvD7dnDDHW56w/BQStE5sZ5aZ2FOyHBE40MswUyW7koztM1EKUsw7ajI4ijB7RP/xZgz8pMLVbnFjiEioEJxmnQR0YAqB8a9cBuJoK49exiOdhsC6iL7D3ko
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
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: Fri, 19 Oct 2012 20:38:37 -0000

On Fri, Oct 19, 2012 at 7:29 AM, Tom Ritter <tom@ritter.vg> wrote:

>>>>>
> The UA MUST observe these conditions when noting a host:
>
>    o  The UA MUST note the pins if and only if it received the
>       Public-Key-Pins response header field over an error-free TLS
>       connection. If the host is a Pinned Host, this includes the
>       validation added in Section 2.4
>
>    o  The UA MUST note the pins if and only if the TLS connection was
>       authenticated with a certificate chain containing at least one of
>       the SPKI structures indicated by at least one of the given
>       fingerprints.  (See Section 2.4.)
>
>    o  The UA MUST note the pins if and only if the given set of pins
>       contains at least one pin that does NOT refer to an SPKI in the
>       certificate chain.  (That is, the host must set a Backup Pin; see
>       Section 3.1.)
>
>    If the Public-Key-Pins response header field does not meet all three
>    of these criteria, the UA MUST NOT note the host as a Pinned Host.
>    A Public-Key-Pins response header field that meets all these critera is
>    known as a Valid Pinning Header.
>
>    The UAs MUST ignore Public-Key-Pins response header fields received on
>    connections that do not meet the first criteria. If the UA recives
>    a Public-Key-Pins header from a Pinned Host that meets the first
>    criteria, but not the following two, the UA MUST discard any previously
>    set Pinning Metadata for that host in its non-volatile store.
> <<<<

Thanks again, Tom. I've adopted this in my copy.

By the way, people can follow my copy here:
https://code.google.com/p/key-pinning-draft

>> (a) simply have the validity time be the same as for HSTS;
>> (b) the same as HSTS but with a 30-day maximum;
>> (c) the current attempt to mirror TACK, except clarified and with examples; or
>> (d) something else.
>>
>> Of these, I think I currently like (b) best. Thoughts?
>
> I think A.  I believe (without evidence) there are institutions that
> would eventually like to use this that have customers that work with
> them on a quarterly or annual basis.  Likewise, I believe (without
> evidence) that a institution who was risk adverse would mitigate that
> risk by pinning to several large CA roots, not by saying "Oh well our
> customers can't access us for the next 30 days, but it's only 30 days
> who cares - but 60, that would be unacceptable!"

Makes sense. Any other votes?

> I do like TACK's notion of 'growing' out pins but only in a "That
> sounds like a feature we're anticipating people wanting" way.  If
> people actually hold off on deploying this because of that and that
> alone, it SHOULD be possible to add a new directive, ignored by older
> browsers who don't implement it.

Makes sense.

> Public-Key-Pins: max-age=600; grow-to=86400;
> pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
>
> The spec should probably note that directives not understood should be
> ignored, and not invalidate the header, to allow for future expansion.
>  Right?

Yes. In fact Chrome's implementation does do that. I thought I had
specified it in this I-D, but apparently not. I propose this
parapgrah:

<t>For forward compatibility, the UA MUST ignore any unrecognized
Public-Key-Pins header directives, while still processing those
directives
it does recognize. <target xref="header-syntax" /> specifies the two
directives max-age and pins, but future specifications and
implementations
might use additional directives.</t>

at the end of the Noting Pins section.