Re: [websec] Gen-art LC review of draft-ietf-websec-key-pinning-19

Chris Palmer <> Mon, 25 August 2014 20:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0656B1A0320 for <>; Mon, 25 Aug 2014 13:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.653
X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2aEP_oP22fqF for <>; Mon, 25 Aug 2014 13:23:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 302011A0314 for <>; Mon, 25 Aug 2014 13:23:58 -0700 (PDT)
Received: by with SMTP id j107so13602338qga.36 for <>; Mon, 25 Aug 2014 13:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4/X6JcmsEBPyvyxqNLvDa/CTH+GWid5Ewri12S6YRIc=; b=H6D67x+VS9bjq2FWC0xVQaobavdH669AD6XVswiDceIJrK3/OwS/1+79va4bsaHiHu JBz913WZ5JP1fpmLs03eMzwrj5pz703l7FaC6cCG+q0M99f99vPIhqquMPf+Hn8hJ0JV 9BHKT3BpLhT5A4kXkiWI8HrhqRTUAqYnMjk5WSOvn0VRK7DjBeKdHNiVz9maJ5Ervvsj OfDcUbgVrOQXr8w9sZlJ98d0WYUxSRwXEiObByWjZIXG6lxSs94QGVMMQCq3motVHXxX 0pziYknZPxpLb3T1ViRRPlw4VSyzperO46izMVPdUCdNY4QppOIJihZo4hFyou5lh40O beKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4/X6JcmsEBPyvyxqNLvDa/CTH+GWid5Ewri12S6YRIc=; b=jpu5J3gtIWjTnw27mRo956gRvSKSKCfnDb2UvGtKQroLsmHV8pQgu4ZAaRQMknVanH hcI36wqKpdlaznCdYloPAm6tP6F2iQXfN/uMMQ3LauXLSJtQ47UCaJG+/5Gwi4WeUUiO gzGi/yNAhrreliV6FThGMgMOVBihnkqLokAoRk84vectWoVUPitSsXDcGAklhw2u1Lpw UdWgdO8B8Lhl34AFmzupc016O3tlLM97XdOwzWrj54M0Q7Vk9SDr8Rik/rVPoHieLNt9 qw8wq2UaB9z58k8kcPROU5vPSFXYObvEtkTZIPqF4auyadpaCnVJzw593TFfzJ2KoFeU M9JA==
X-Gm-Message-State: ALoCoQkvHqIzwMxl3vPCFakT1+MvNWv/YaTvyBKw04C1gKm7T73G+coFqW7I0nBWka9dcDciir7I
MIME-Version: 1.0
X-Received: by with SMTP id l108mr36202786qge.29.1408998237177; Mon, 25 Aug 2014 13:23:57 -0700 (PDT)
Received: by with HTTP; Mon, 25 Aug 2014 13:23:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 25 Aug 2014 13:23:57 -0700
Message-ID: <>
From: Chris Palmer <>
To: Elwyn Davies <>
Content-Type: text/plain; charset="UTF-8"
Cc:, General area reviewing team <>, IETF WebSec WG <>
Subject: Re: [websec] Gen-art LC review of draft-ietf-websec-key-pinning-19
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Aug 2014 20:24:00 -0000

On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <> wrote:

>>>> s2.1.1: I'm not sure if this could be an issue.. should a maximum
>>>> possible value for max_age
>>>> be specified to avoid UA's being cluttered up with old Pins - this might
>>>> possible be a DoS
>>>> attack vehicle but I am not sure (yet) if it could be. OK.. so s2.3.3
>>>> talks about limits.
>>>> A pointer to this discussion would be useful here
> A pointer to the discussion in s2.3.3 would still help.


> Ok.  Accepting that the host is expected normally to send the headers on all
> responses, when SHOULD it not send the headers? (from the previous comments
> a server that knows it is not multiplexed might be a candidate - or if it
> knows it has already responded on this connection?)

I think it's easiest and simplest for servers to simply always send the headers.

>>>> s2.3.1/s2.4: S2.4 states that hash algorithms might be deprecated in
>>>> future.  Presumably a
>>>> deprecated algorithm should be treated as an unrecognized directive or
>>>> some such to avoid
>>>> downgrade attacks.  Probably worth being explicit about this.  Also this
>>>> is potentially
>>>> incompatible with the statement that 'UAs MUST recognize "sha256"' (Para
>>>> 3 of s2.4).
>>>> This results in a potential downgrade attack when and if SHA256 is
>>>> deemed to be no longer
>>>> cryptographically effective. I think this statement can be removed as
>>>> presently a UA
>>>> has no other option if it is to implement the specification.
> Not addressed as yet.  At least the statement in s2.4 needs to be removed.


>>>> Also there may be some of the questions in s8.3.1 of RFC 7231 that need
>>>> specific answers.
> There are still some of the questions that ought to be explicitly answered.

To me, the only questions that might not have obvious answers are:

   o  Whether the header field is useful or allowable in trailers (see
      Section 4.1 of [RFC7230]).

Surely not? For the same reason we don't want it in meta http-equiv.

   o  Whether the header field ought to be preserved across redirects.

Surely not?

Any others?

> One extra nit:
> s2, para after bullets: s/reistry/registry/


Changes visible at I won't push
a version 21 until I've gone through the rest of the incoming email.

Thank you!