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

["Stephen Farrell" <[e-mail]>]

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?

(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?


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

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? 

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.

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?

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.