Re: [websec] Richard Barnes' Yes on draft-ietf-websec-key-pinning-19: (with COMMENT)

Ryan Sleevi <sleevi@google.com> Wed, 06 August 2014 20:00 UTC

Return-Path: <sleevi@google.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 ACE4F1B27DB for <websec@ietfa.amsl.com>; Wed, 6 Aug 2014 13:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 MPj18DeIAkdp for <websec@ietfa.amsl.com>; Wed, 6 Aug 2014 13:00:46 -0700 (PDT)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15B31A00F1 for <websec@ietf.org>; Wed, 6 Aug 2014 13:00:44 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so4760712vcb.8 for <websec@ietf.org>; Wed, 06 Aug 2014 13:00:43 -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; bh=NQKyHeEztW8//wHfhxaVcnz13w4GhIgqcgoCoj8g920=; b=R48afVc73MwCMGLspPgwOnjscq1omq8rH2HXTmqlAbH6wjtC0M6wwuTvUd0ZiPNf7e w5VCznqcTohfFS+jgPsMChc5vHaDmuc4tqHDYZ+tdcnoDKubG1g9u5YpVs4j5gTf/F9t Kt/g8rkvG8WMlF2tknC+lgCOHxArpc7aHBfABwTX/dRua6aVKOetGQH/0yjWBK1ZUXKI KcNvkCLxdWuzCiAU5EtCeYHn72Mni63pYaRd8W4r7CRJ6gkYWiEtvEcLLbZOFKXx/ArQ XJc0YC9ewooQEmRzPwaJoFNw7TL4tf8XxSUkzbfkedzjLrGtFu0xpz0kJ0Sd/HVBXC5d X7Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NQKyHeEztW8//wHfhxaVcnz13w4GhIgqcgoCoj8g920=; b=lCONB8uvZnnu90gZ+Pvn081IWGdGV0oc9lQ2cvcvGZD7lDYYGOIpljNryWUL2Y9zTr spK/jeqLJjyR4r8YsO0kIh7hTFCATrof5lG+0QOir2Ub0gEZ64QSqKSMg1+Oo7WdEhux 6uzxFBFturplSKkrHY6ILj8Bp9lugVxHqjp4XooU0HPp/CkEgNJlWlpHoFQjwoEiN1QH Ks9K4HM0ZIuvwH7J7hJgExvYAr2sEUAGA/QzHK5PNT6y7evSLR6wVwvCfcxiM54/3MMQ slBdy06dj2Sm+XTcsginNvqBe6WsCzNWx+GXJbyGI2VFjz9Loe93ecnjvtFpRH6kmu6H RlAw==
X-Gm-Message-State: ALoCoQmIeqAR9J9APmSBQi9uoCE3jYb+RWtGpDhJhHKwN5gJUIFE+vAThzdB3D+cwJu5hvSp2sbC
MIME-Version: 1.0
X-Received: by 10.220.82.202 with SMTP id c10mr12628823vcl.31.1407355243791; Wed, 06 Aug 2014 13:00:43 -0700 (PDT)
Received: by 10.52.139.78 with HTTP; Wed, 6 Aug 2014 13:00:43 -0700 (PDT)
In-Reply-To: <20140806192308.15466.52635.idtracker@ietfa.amsl.com>
References: <20140806192308.15466.52635.idtracker@ietfa.amsl.com>
Date: Wed, 06 Aug 2014 13:00:43 -0700
Message-ID: <CACvaWvapKThsHPQPzoJ0BZVwea8fnm5O+OMAHFxdcZudp=MCjw@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="047d7b339fc161232f04fffb6d04"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/sxQypNVhb2IgN60HuFHaPpYx_yo
X-Mailman-Approved-At: Wed, 06 Aug 2014 13:03:15 -0700
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, "<websec@ietf.org>" <websec@ietf.org>, The IESG <iesg@ietf.org>, websec-chairs@tools.ietf.org
Subject: Re: [websec] Richard Barnes' Yes on draft-ietf-websec-key-pinning-19: (with COMMENT)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 06 Aug 2014 20:00:48 -0000

On Wed, Aug 6, 2014 at 12:23 PM, Richard Barnes <rlb@ipv.sx> wrote:

> Richard Barnes has entered the following ballot position for
> draft-ietf-websec-key-pinning-19: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This is an important document, and overall clearly written.  There are a
> few points that it would be good to clean up.
>
>
> Introduction: "At least one UA..."
>
> FWIW, this is now "At least two UAs..."  Firefox also has a manual pin
> list as of version 32, currently in Beta.
>
>
> Introduction: "but is possible to pin keys without requiring HSTS"
>
> -> "but it is ... and vice versa."
>
>
> Section 2.2.2. "Pinned Hosts SHOULD NOT include..."
>
> This applies not just to Pinned Hosts, but to any web host, right?
>
>
> Section 2.3.1. "If a UA receives more than one PKP header field ... only
> the first PKP-RO header field (if present)"
>
> This seems problematic in light of the fact that HTTP recipients are
> allowed to coalesce the values of multiple header fields.
> http://tools.ietf.org/html/rfc7230#section-3.2.2
>
> So, for example, if header coalescing were done at a lower layer in the
> HTTP stack than HPKP, then the pinning code wouldn't be able to
> distinguish "first" vs. "rest".  On the other hand, maybe this is a use
> case for using semicolons as separators, since the combined header field
> would not be valid.  In either case, there's a need for updated text.
>

Note, same issue applies to http://tools.ietf.org/html/rfc6797#section-8.1,
which is the source of this language.

This appears to be RFC 7230 changing the rules that RFC 2616 set out,
incompatibly.

RFC 2616 reads
"Multiple message-header fields with the same field-name MAY be present in
a message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]"

In this respect, both this draft and 6797 are compliant with 2616.

RFC 7230 changes this, incompatibly, to read
"A sender MUST NOT generate ... unless it's defined as a comma-separated
list [i.e., #(values)] or the header field is a well-known exception"
"A recipient MAY combine multiple header fields with the same field name,
..., without changing the semantics of the message, by appending each
subsequent field value to the combined field value in order, separated by
comma."

So this is clearly something that 7230 changed from 2616, in a way that
provides a more liberal interpretation than 2616 allows.

As addressed earlier on review, because semi-colons are used, if a
recipient did coalesce, then such a header injection would cause the
pinning header to be ignored (as invalid), rather than processed. That
still seems to be acceptable behaviour - e.g. no language change required.


>
>
> Section 2.5. "at least one Pin that does NOT refer to an SPKI in the
> certificate chain"
>
> I understand the motivation for this, but this doesn't actually force the
> site to have a backup pin -- they can just make up a pin value.  It seems
> like it would be more effective to make the recommendation in Section 4.3
> stronger.
>

I'm not sure what you see as a viable change. There's no way that a UA can
confirm a Backup Pin is a valid backup pin, short of requiring the key be
online and capable of proving itself, which is precisely what having a
backup pin is to help you avoid.


>
>
> Section 4. "Security Considerations"
>
> Most of these seem more like "Operational Considerations" or
> "How-To-Not-Brick-Your-Site Considerations".  :)
>
>
>