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

Ryan Sleevi <> Mon, 06 October 2014 00:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 170171A01D8 for <>; Sun, 5 Oct 2014 17:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.249
X-Spam-Level: *
X-Spam-Status: No, score=1.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oVoE3klhEIez for <>; Sun, 5 Oct 2014 17:57:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A92991A0004 for <>; Sun, 5 Oct 2014 17:57:54 -0700 (PDT)
Received: by with SMTP id hq11so2467414vcb.7 for <>; Sun, 05 Oct 2014 17:57:53 -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=KmGX0sKy/lRyO8+Z5lXGqHXqHXKwhkbMDw1iqOh6VR8=; b=HubyrVxkN2s24xD6a1VWDYicAK6+MvJiXmBDyWmtrau/36kq6MlBN275CS3xmJzc09 qlwjlFj8JAQz2NL7Ss/iIAE7yAzzcMcasKtNB6IuLrIFtLmpadkkmsmivlp7F4ALFdBc ln7bEAa0TTJ5AOLRemJ/w6pv8TtGbTnxgR17H1GXjTQczDFk6KlTj5J2r2LiEKpP2Q7i MCGRMSwMvbH5dSugYbHiqXd+uLVw2H5Us61RYrFGak6NavTBFU6mhEcYra9FcYZXXQx4 PoZuErqx/zTGvT+gc9VgnY66Zl8tJ4NJLisPDIRAYjl5edydhEKOwXTe7PhD2DeaZiQ6 8vMw==
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=KmGX0sKy/lRyO8+Z5lXGqHXqHXKwhkbMDw1iqOh6VR8=; b=Y7e2VX8ALnGTVoczQCkpNXEA8QcZ2FJ8u5+IK62EuemBflOr23luDKKyR+P3z1xzW+ UbExAhvDgCjrg8rSqNYFUVQ20iCSBKDAFPIjBS8HNbpBAb3zgN1YwV4b87/YEFW6/MI3 jdrdfa0z6Fq4pgfMu7WEA9QJawYoN3IBHq2TdrzrC5bGFf35mif47LJGzcM/7SaIid+v HKMfxAP5EyOCOlUB3DQDITzixpiJkBKCXPxdwhNKFkFZnAlDP+hEeEBfxPYo+p+iBrBE 2SzSUqI2mYPdSUAEcTeOekgO8aHOxsEXWegtcOJ5pnCf373IcxS4wHd5DietGBpu8GK3 GiSw==
X-Gm-Message-State: ALoCoQnpZUH5/d/ZVPcw+GaR3krEkVtg7fOuBAAhcHyzrK/NgHmCV/d+Qy9xAURhAI0bS0Vij0Zv
MIME-Version: 1.0
X-Received: by with SMTP id r8mr15542447vcx.21.1412557073674; Sun, 05 Oct 2014 17:57:53 -0700 (PDT)
Received: by with HTTP; Sun, 5 Oct 2014 17:57:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 05 Oct 2014 17:57:53 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Elwyn Davies <>
Content-Type: multipart/alternative; boundary="001a11c214129a0cbb0504b69219"
X-Mailman-Approved-At: Mon, 06 Oct 2014 08:08:38 -0700
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, 06 Oct 2014 00:57:57 -0000

On Sat, Aug 30, 2014 at 11:42 AM, Elwyn Davies <>

> Hi, Chris.
> A couple of remaining points and a couple of nits/queries in the fixes.
> I have deleted the items that we are agreed on below and added comments in
> line.
> New nits:
> s2.6, next to last para: s/previous/previously/
> s4, lasta para:
>> and indeed MUST pin to issuers not in the chain
> Is this a requirements MUST?  The protocol will be quite happy and
> implementers can't (at least I don't think) they can check if the host
> leaves it out.  This is operational advice (admittedly highly relevant) but
> still advice I think.
> On 25/08/14 21:23, Chris Palmer wrote:
>> On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <>
>> wrote:
>>  <<snip>>
>  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.
> Having thought about this a bit, I don't think this text fully reflects
> what is going on in the server.  If I understand correctly, we have:
> - Server has a policy that it wants to be pinned if it can be (presumably
> this ought to be configurable in the server).
> - When a client sends a request over a new secure connection and the
> policy says 'be pinned', the server sends back pinning header(s) in the
> response.
> - Thereafter, it MAY for simplicity send pinning headers in all subsequent
> responses on the connection. Alternatively it can do something intelligent
> and not bother sending the headers if it is the same connection - but of
> course this probably means a layer violation.
> Thought: Does it make any difference if the client doesn't accept the pin?
> Should success or failure be logged?  Should the host always keep sending
> the headers if the client didn't accept the pin on the first
> exchange (is this a possible symptom of a MITM?)?
> Suggestion:
> OLD:
> 2.2.1.  HTTP-over-Secure-Transport Request Type
>    When replying to an HTTP request that was conveyed over a secure
>    transport, a Pinned Host SHOULD include in its response exactly one
>    PKP header field, exactly one PKP-RO header field, or one of each.
> NEW:
> 2.2.1.  HTTP-over-Secure-Transport Request Type
>    If a host has a policy of becoming a Pinned Host whenever possible,
>    then on replying to an initial HTTP request that was conveyed over a
>    secure transport, a host intending to become Pinned Host includes in
>    its response exactly one PKP header field, exactly one PKP-RO header
>    field, or one of each.  The host MAY include the same header(s)
>    with any subsequent responses using the same connection.
Just to cycle back on modifications, I've opted not to make this
modification, as it violates the independence of HTTP Request/Responses.
That is, each Request/Response over a given Connection is meant to be
treated in isolation.

The language proposed, while possible, also misses out on edge cases like
HTTP pipelining (and figuring out when pinning takes effect) or the
semantics of HTTP/2.0, which allows connection pooling ( )

> <<snip>>
>  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.
I'm ambivalent about this. I treat headers - leading or trailing - as part
of the security boundary of a server. I'm not keen on violating any header
semantics here.

>>     o  Whether the header field ought to be preserved across redirects.
I don't see any problem here, because it's a Response header, not a Request

>> Surely not?
>> Any others?
> The point was that I guess you ought to explicitly say "not" in each case.
>>  <<snip>>
>  Changes visible at
>> I won't push
>> a version 21 until I've gone through the rest of the incoming email.
>> Thank you!
>>  Cheers,
> Elwyn