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

Ryan Sleevi <sleevi@google.com> Thu, 28 August 2014 01:14 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 2AFE81A0457 for <websec@ietfa.amsl.com>; Wed, 27 Aug 2014 18:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 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.668, SPF_PASS=-0.001] autolearn=ham
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 nQOYroEGpwSP for <websec@ietfa.amsl.com>; Wed, 27 Aug 2014 18:14:13 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95171A03DE for <websec@ietf.org>; Wed, 27 Aug 2014 18:14:12 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id im17so90783vcb.32 for <websec@ietf.org>; Wed, 27 Aug 2014 18:14:11 -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=uBwwB3iYU0DJJtlxL9CXXgrNQtRE6WZicjZnntLLrCk=; b=Ve7lS/iAcG3nJm7BtJdtp61xzIdVLukIwV7N5YGfkp0cyjraSBEGdKFLB21WZXTQlg W9Xsa0twFjMz7KylmVjVUsv8ggdd3eDYcuS4qgGSKWoGKSGaHCjYNkva6rwWf1ycMsNQ nhMLg33bv/fmu33aFnD86bICcWsEjG9ZpLapSGjXPwEVZAwPjG+M+qYxqvWaXqbgT9Pm 63TeATMng23BkPKLs15NhVvWUhHjZc5W5+Ift2ovYBEdQEeE4M5f5Oa8SKq9gI5HuRV2 zlzN6OsaF8LALxXhkz0FU829PZVtHBjM5+c/cKFmYjLUqp1aWtY6+yCEnydQh/LudazG OfwA==
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=uBwwB3iYU0DJJtlxL9CXXgrNQtRE6WZicjZnntLLrCk=; b=PlecxrjY2Ri7EXJ2cpev7xjZxgISiqRzYDothqYYBA5gvcRXp63s7HGS3e88LVioA2 9PdKWwQrCI3p+hLqI9l90imxA8c9YMPi7vnzvorY71SGgL9Pm9KiZ4QzaYxjQ7ndouzL LuhL1Ex5qEacwTkNO/5n3mtsrmuKzL/08cPfgHyvqMvD/vu7qdLcLQhVsimdg+oal+kp xoMkczP0aLHTdlvoNKOcynD5ZxY1cWjQZktYRA5JbeqG+U29QaKY4h5wU/BOGzXB0TS8 0Q5lrZXIOZwhbXTNSlDjZL3OFqrwAY9k9AvoWn/dnXhnQe39WLE/0NozTGCcSU+zRUmN W0Vw==
X-Gm-Message-State: ALoCoQmBO0SrIHH8UrTh0HDjM/ptkfj2MNVLirQ69a9soP9ci57YSLMITOg52qKI7Rt8pR9ONIu0
MIME-Version: 1.0
X-Received: by 10.52.32.230 with SMTP id m6mr445096vdi.74.1409188451663; Wed, 27 Aug 2014 18:14:11 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Wed, 27 Aug 2014 18:14:11 -0700 (PDT)
In-Reply-To: <CA+cU71=gTW1ePN9HX4urTDktF-RohgrmYP_jRgKVStQ4F7QP6w@mail.gmail.com>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <CACvaWvYHAmpX0f9_m-sckhWz9tcyWA-sxVR4vP-A5UcAQmnYXA@mail.gmail.com> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <CA+cU71k-pLD315dzfd_c74QM51c7V2VQkZ26PiXUTqntmESD=A@mail.gmail.com> <CAOuvq20mZkScvPDKjsa1eZ6rdoHxf_+oF=gpaOcvkOTaYhyj6Q@mail.gmail.com> <CA+cU71mW47OvqRNTbw-H7u-F_k6hMv4xr0XcMYAS_V6eE8brwA@mail.gmail.com> <CAOuvq20C+T9Ejf_KUsfPRtUWL7ggCF0UWJZkGr5xGBEkERXeRQ@mail.gmail.com> <BAY169-DS45D73636AA204DEEABC876AEDC0@phx.gbl> <CAOuvq20kCKk=jcXsy_d8C-4Fn-f0zshP6YUPn5N8hsKt7KO7dw@mail.gmail.com> <CAGZ8ZG3KUPAbePp-_GCztj4RSLd8MuNo1iDz=ua+BEjQVzJc7Q@mail.gmail.com> <CA+cU71=A6vFXZrG8mcqj4uC-z2VdJfFOutqcq9MPTYs+uhpa9Q@mail.gmail.com> <CAOuvq22QgGVpsxrsZswqspiP-rgNE6B3vp_6bYDTE5-MrLZdVg@mail.gmail.com> <CA+cU71nN-=TjWZZovMUcTrXMF1gBcYFppnfnsaP7hKw+6AUCLQ@mail.gmail.com> <CAOe4Uim9ZC7MdY1tXhLWFwNxzxorh00bJ3PBsco_H-KxpYh-Dg@mail.gmail.com> <CAGZ8ZG3xoA1w1oEx9F8MuH1PARe5ALU9A1CEXqDXM-JSh_niGg@mail.gmail.com> <CACvaWvYjVXMsgCzL=mM+F8eS0hcjTqEaR7xYzti4LD4rdpbD1g@mail.gmail.com> <0EBE1766-612D-442E-B2B1-149D368144D4@gmail.com> <CA+cU71=gTW1ePN9HX4urTDktF-RohgrmYP_jRgKVStQ4F7QP6w@mail.gmail.com>
Date: Wed, 27 Aug 2014 18:14:11 -0700
Message-ID: <CACvaWvZNpAepBmWchLMirfPdxu4ed=vH1qwMppAjw1P9S+4quw@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: multipart/alternative; boundary="bcaec517c4b2155c0f0501a64121"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2En_bqwA-WRBh9LtayZ9ziCmomc
X-Mailman-Approved-At: Thu, 28 Aug 2014 07:35:28 -0700
Cc: draft-ietf-websec-key-pinning <draft-ietf-websec-key-pinning@tools.ietf.org>, Eric Lawrence <ericlaw1979@hotmail.com>, "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] draft-ietf-websec-key-pinning
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: Thu, 28 Aug 2014 01:14:15 -0000

Right, so, I do agree with Joe that I do think we've reached conclusions on
the suitability for security and the suitability for testing, and I do want
to see what can be done to editorially resolve this.

Without having fully drafted the text, it seems like one possible solution
is to describe HOW a site operator might use this to test deployment of
pins, knowing that it may not be a perfect solution for all use cases, it
would at least help to clarify both the strengths and limitations.

The example I'm thinking of is as follows:

-- Begin
Site operator deploys PKP-RO on their domain
- In order for this to be useful, the assumption here (and which I think
had always been implicit, but it may help to call this out, in several
places if necessary) is that PKP-RO does not require that the current
connection MATCH the pins in order to send a report (otherwise, you'd never
get a negative report, because you'd never evaluate PKP-RO in the negative
case)
- They gather data from their users, which may include information about
possible certificate chain paths that they were not aware of (assuming a
publicly trusted CA with UAs with different trust stores, etc)

After gathering data, they deploy PKP, which makes the RO now a hard fail.
They may still use report-uri with their PKP header, along with shorter
timeframes, to ensure no critical errors were missed

Now it comes time to gather in the sub-domains, the site operator works
through their (known) subdomains with PKP-RO, doing the same steps as they
did for the parent domain, setting PKP on these subdomains.

Believing they have gathered all their subdomains into a unified policy,
they then work to set PKP on the 'main' domain with includeSubDomains +
reportURI set.
They likely do this in small bursts, temporarily decreasing the max-age of
the 'main' domain when setting the includeSubDomains (e.g. perhaps 1 day or
even 4-12h), examining reportURI for failures, and then turning on their
sans-includeSubDomains policy with the longer max-age

Finally, believing to have gathered sufficient data, they turn on
includeSubDomains (with report-URI), and have the whole system protected

-- Fin

As Eric noted in HSTS, this may include having the subdomains either set
their own policies (for redundancy/safety, but at the tradeoff of
potentially conflicting pin policies, as already noted), or having the
subdomains source a resource from the parent domain (which causes them to
fetch/detect the includeSubDomains from the parent domain)


The assumption here, and I realize is perhaps unfair for some use cases, is
that you know the sub-domains you wish to protect. Hopefully a competant
domain administrator was responsible and this information can be
discovered. The short-lived PKP+includeSubDomains+reportUri provides an
added means of testing, but is admittedly 'more' heavy-handed than simply
PKP-RO with persistence.

PKP-RO with persistence is, I think, dangerous. In the naieve form, it
allows a MITM to setup a DOS bomb against a legitimate server, by setting a
PKP-RO to report errors. Unlike a PKP policy (which is detectable by the
user, by virtue of fail-closed), whose fail-closed nature may indicate to
the user that somebody set them up a bomb, a PKP-RO is conceptually and
practically silent to the user, which may cause the user to flood the
legitimate server with reports once they're away from the MITM. Now, we
could tweak how persistence works for that case, but I think as we do, we
get further and further into a complexity that may require significant
edits/reviews. We can do that, but I gather the spirit, both of the editors
and, from the responses, those involved in this discussion, that it's not
necessarily something felt too strongly about.

The question is, does the above scenario sound reasonable enough to
include, perhaps in an "operational advice" or some form of appendix, that
provides guidance on how the existing primitives can be used, but also
highlights the limitations of the current primitives so as not to cause
confusion?


On Wed, Aug 27, 2014 at 5:26 AM, Tom Ritter <tom@ritter.vg> wrote:

> On 27 August 2014 05:46, Yoav Nir <ynir.ietf@gmail.com> wrote:
> > At this stage, we can make editorial changes, but we cannot make
> significant
> > changes on our own. We can withdraw the request to publish, and take it
> back
> > to the working group, but I think that would be inadvisable.
> >
> > I think we should proceed, making only editorial changes, and changes
> > resulting from discussion with IESG members.
>
> If adding a note in 4.2 about includeSubdomains and PKP-RO (for
> testing) counts as editorial, I think that is worthwhile.
> Otherwise/regardless I also don't want to withdraw.
>
> -tom
>