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

Tom Ritter <tom@ritter.vg> Wed, 17 October 2012 14:23 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 CADE721F84B6 for <websec@ietfa.amsl.com>; Wed, 17 Oct 2012 07:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level:
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 9ZUl2RHoXxFX for <websec@ietfa.amsl.com>; Wed, 17 Oct 2012 07:23:51 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A18F221F851C for <websec@ietf.org>; Wed, 17 Oct 2012 07:23:45 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so8245881vbb.31 for <websec@ietf.org>; Wed, 17 Oct 2012 07:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JRIsQQ4HGfSYJp8FUr7cRh0sRVIgKlhXC9rU+YcvH5c=; b=zZdJVhX6dCjgGzfwziMHcSY0KDmJfLptkfdEdr1g2r8h/dOxfkju8ytL6tG1CU4i/z iKiJmHx6RrFk6wKW/E/5XhJ8hvyB80JrRgyejyw50qcoha1gJXAzoWsFOiu1Xtf2zt6L RX2a4QWRdwggR1WlPr3A1LkEf1TLHXQpQPPP0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=JRIsQQ4HGfSYJp8FUr7cRh0sRVIgKlhXC9rU+YcvH5c=; b=l8QC4d8khlAsC+x3pARKJW6L/q7dgEB75CZhO2taM/QfEebBdzEDkZvty6a5uiz1Ek Vai3DyvN+MJNjyfHVF+PTp+hS4NH8egdm+O+rHqPqX1VSAFp1A69n3utSZZHnZ0OIzOt DiRP8xM/7fm2gZYDu0uT6RTrDQNuginFhoZfqlKjqYEcDZ3AeSa5zIq6OGHHktySkLvu jXNGGwR+V43I77XHQFug7FcITG6k9EBoGe5rXUkhcoqNWgTEsXs+tQYoFAeMGmzfNnu7 0bgfMULCM5UT3VGm7vBS/u+ZYE316HuOuYk6UMAdlqh8uu0gvy/yZ4QkEle7BvMxciDS lQ4Q==
Received: by 10.58.239.162 with SMTP id vt2mr6723553vec.1.1350483824308; Wed, 17 Oct 2012 07:23:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.151.178 with HTTP; Wed, 17 Oct 2012 07:23:24 -0700 (PDT)
In-Reply-To: <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com>
References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <CAOuvq219yJ1P1STBM-AkP7aLNP1W_U8WYp2v-8x1kzXuS_VT6A@mail.gmail.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 17 Oct 2012 10:23:24 -0400
Message-ID: <CA+cU71kDB19HTgJ0AiH42ErLuRLGJDavqm3boV-Hifyjjy4TgQ@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQn86THlmscG6u5gfjAFlXFNDc6RbsgcymywJxucUhWTEPS2GKSoCyYD9Bp844woAGG14dcb
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: Wed, 17 Oct 2012 14:23:53 -0000

Some musings after reading again:

Section 2.3 "Noting Pins":

I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins
response header fields received on HTTP (non-HTTPS) connections."
outside the criteria to be unambiguous that a client should not
"discard any previously set Pinning Metadata" if it receives the
header over HTTP.  Or if it's reasonable enough to assume no one would
get confused.

Similarly, I wonder if there was some situation that could result in
an attacker-induced 'errored' TLS connection that still sent the
header, resulting in the data being discarded...

Section 2.4: "Validating Pinned Connections":

   For the purposes of Pin Validation, the UA MUST ignore
   certificates who SPKI cannot be taken in isolation and superfluous
   certificates in the chain that do not form part of the validating
   chain.

I know I just modified this, but the second phrase just hit me.
Because path construction is non-standard, could a client wind up in a
situation where the site pinned to CA_Alice, with the intended path
CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
trusted, the ultimate validating chain was simply CA_Bob ->
Intermediate -> Leaf?  I'm not sure what the right way to counteract
that would be...

2.5: "Pin Validity Times"

I find the "current + current - initial" / "(b) the amount of time the
pin has been noted" item confusing, and am not sure what it means from
reading only the draft.  If I'm not the only one, it might be worth
clarifying.

2.6.  "Interactions With Preloaded Pin Lists"

If closing private browsing mode or clearing saved data also clears
preloaded pins (and I think it should), this would cause a revert to
the preloaded pins, which may break sites.  A workaround may be to
disable a preloaded pin if a new pin is seen, and keep that disabled
even after the saved data wipe/private browsing mode close.  To
prevent using this as a backdoor into tracking, the preloaded pins
should be sanity checked for "Is this organization likely to abuse the
feature."



Again, excited about this - thanks for the work.

-tom