Re: [websec] Stephen Farrell's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)

Ryan Sleevi <> Mon, 25 August 2014 05:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F3AA1A8A63 for <>; Sun, 24 Aug 2014 22:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fkW2NlTQTHbt for <>; Sun, 24 Aug 2014 22:52:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 005D91A8A65 for <>; Sun, 24 Aug 2014 22:51:52 -0700 (PDT)
Received: by with SMTP id im17so14644951vcb.31 for <>; Sun, 24 Aug 2014 22:51:52 -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=huJmF/UN7+UDPJHeBzm9fBWD3X6bXGW6s/Q17EwaUqU=; b=l//9BtTorkJxkkK99ssyoPy9bC/A4/WwGHG1Mmtm1VFW2TrQqCpmCxVvEge53OFH1n x80AN1FCmBkDEhM79czJgqzQs0rUUGhw1nipJ90Up0tZsuMJYYTR+cP4MOkc8SesjEBX 2EurotXoFvS2IgVlw6lcZSo6CTnCidLnTg3H8D5mdaurKrrH0Cz+O4ej9/+Pd9ZIC3Ug W6yNI77aVA2IH0ldShrH/994TbrxyfEXGex4dM0PiaTJoYHSMq5q9CaQPdWMASl0lTst /qXaMG1LqMNcrxklfosyeC405Eai8d5wCTXyK0FHgwZ9IpRu4pqum47yhmVpjrgjAsSj gljQ==
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=huJmF/UN7+UDPJHeBzm9fBWD3X6bXGW6s/Q17EwaUqU=; b=b6gDYDysH6paFAK6hZVCqEmCkKuo4//Wquyp/lFCfvoDrKuv8LPKQcU+s+rAYc0kQe mutzt/ucm0/H/iXF4LsvRFhOOfG/zcyS9rovVKH0u7CY1tPQmzXe4dY8nH5MGZPcQP3m hR4GSiu6OJTA1X5RNOu+iXJO5zHKusJPJRtEX+adQIElzYfBKsOH4yKbXWtP0XS1ntPM 8LmEr6Ig9bdv08R4rzhZ4K6DwjN8Wkwx2jpB4U1VpjuXfOdVGoJ10JUrD2L4uGCCODwU f2hRvic9VGslvIKyq59j5T5tx822AUKdN43UlN6BcR6epI7KJFeolp1lIJuGPBqyPjL4 Y6Hg==
X-Gm-Message-State: ALoCoQnXuAFxEDqj5fwuicixZJJVCQy744mE7vF84mbIQQVHL4Q9m+zZm1l78iuWaU2ZNc89Nk68
MIME-Version: 1.0
X-Received: by with SMTP id qt9mr4061462vcb.39.1408945912182; Sun, 24 Aug 2014 22:51:52 -0700 (PDT)
Received: by with HTTP; Sun, 24 Aug 2014 22:51:52 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sun, 24 Aug 2014 22:51:52 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary="001a1133955c9aa20205016dc83f"
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Cc:, "<>" <>, The IESG <>,
Subject: Re: [websec] Stephen Farrell's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)
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 05:52:15 -0000

On Thu, Aug 7, 2014 at 4:07 AM, Stephen Farrell <>

> Stephen Farrell has entered the following ballot position for
> draft-ietf-websec-key-pinning-19: Discuss
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Good doc. Two things I'd like to check before moving to a yes
> ballot:
> (1) 2.1 - Can a simple-directive start with "pin-"?  Seems like
> yes it can, but then the ABNF is ambiguous about the RHS of the
> "=" I think, is that right? Its no big deal since valid values
> will parse anyway, so only an issue if you ever care about
> simple-directive vs. pin-directive. Ah - does the last para of
> 2.1 mean that this distinction is needed really?

>From the ABNF, yes, it does many any simple-directive can start with "pin-".

I suspect the solution is to remove pin-directive entirely from the ABNF,
as it's not necessary, and purely specify in terms of directives. The
concept of a "pin-directive" can be explained via prose, which would be
consistent to how HTTPbis restructured most of the header processing.

> (2) 2.1.3 says that "If the scheme in the report-uri is one
> that uses TLS (e.g.  HTTPS), UAs MUST perform Pinning
> Validation when the host in the report-uri is a Known Pinned
> Host;" That's generally ok, however, I think it may break for
> alt-svc, where TLS is used but https is not, or if TCPINC
> decided on a TLS based solution then some coder might get it
> wrong. I think a simple re-statement in terms of http vs. https
> URIs should fix this. I realise that neither alt-svc nor TCPINC
> existed when this work started, but since they now do it'd pay
> to think about them and I don't recall seeing that on the
> websec list (apologies if I'm wrong there).  The IFF in 2.5
> also seems related.  2.2 has same issues about alt-svc and
> TCPINC. I do see that you only say "e.g. TLS" here but
> wonder nonetheless, e.g. would 2.2.1 cover an alt-svc case
> or not?

The suggested solution - being explicit that it applies to HTTPS - equally
suffers from the risk of error being seen for alt-svc, in that it fails to
account for schemes such as wss://, for which pinning also should apply.

I realize this is probably something you may not agree with, but I think
the language choice here - that of "secure transport" - is already
sufficient to exclude such proposals as alt-svc, which only provide
encryption. That is, both in practice and intent, alt-svc is not considered
to be a "secure transport" (which is as much evident by the lack of secure

For example, with respect to 2.5, the second bullet point describes the
connection as "authenticated", which alt-svc is not.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> abstract and elswhere: SubjectPublicKeyInfo doesn't usually
> have spaces between the terms. No big deal. After the abstract
> would a ref to 5280 be right for SPKI as well?


> general: I think emphasising the backup pin requirement in the
> intro would be good. It's a little hidden now and would be a
> surprise to some I bet.
> 2.1 - pin-directive has the literal "pin-" but later you say
> (in bullet #3) that directive names are case insensitive.  Does
> that apply to "pin-" as well or not?

It should. The above proposed removal of the ABNF for pin-directive should
remedy this.

> 2.1 - has some typos: reistry and hahs
> 2.1 - "Known Pinned Host" would be a fine term to define in a
> section 1.1 that was renamed via s/Requirements
> Language/Terminology/
> 2.1.1 - max-age is really defined against the time of reception
> and not (in principle) from when its emitted?  I know that
> makes no difference now, but with a sufficient latency (e.g.
> Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage
> is showing:-) it could, just about. I think to be pedantically
> correct, max-age ought be defined versus the time of emission
> and not receipt.

I don't see how this reasonably can be accomplished, short of requiring
that the Date header ( )
be present, which does not seem desirable.

> 2.1.2 - uses the term "Pinned Host" which is not the same as
> the previously used "Known Pinned Host" - is the distinction
> meant to be significant or is that a typo?

Typo, although the difference is significant enough to provide
clarification, in as much as it applies to PKP-RO (which doesn't note the
pins, as discussed elsewhere)

> 2.1.3/section 4 - shouldn't the potential DoS issues be
> discussed for cases where report-uri != same-origin? E.g.  if
> (is hacked and) sets report-uri to
> (maybe with some HTML/JS that generates
> loads of queries to the victimj) that'd be like getting /.'d I
> think that's maybe worth noting in the security considerations
> or in 2.1.3 where you (quite properly) say to rate-limit
> reporting. If you'd rather not say why though, that's ok too.