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

[Ryan Sleevi <[e-mail]>]

On Thu, Aug 7, 2014 at 4:07 AM, Stephen Farrell <[e-mail]>
wrote:

> 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
>
> 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
cookies)

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


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>
> 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?
>

Sure.


>
> 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 ( http://tools.ietf.org/html/rfc7231#section-7.1.1.2 )
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
> busy-site.example.net (is hacked and) sets report-uri to
> victim.example.com (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.
>
>
Sure.