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

[Stephen Farrell <[e-mail]>]

Hi Ryan,

Thanks for the thorough response. A few bis'n'pieces below but
I'll clear once you've posted the update, so no need to keep on
chatting if you prefer that. (I'm happy to keep chatting too of
course.)

On 25/08/14 06:51, Ryan Sleevi wrote:
> 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.
> 

Grand. That'll fix it.

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

Fair enough.

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

You're right that I do think some more clarity would be good. Isn't
the fact that we both think coders are likely to make mistakes here
a good indicator of that?

I'd suggest adding something like:

   Note that only server-authenticated TLS or mutually-authenticated
   TLS are considered "secure transports" for the purposes of this
   specification. In particular, any form of unauthenticated TLS such
   as use of *ANON* ciphersuites or opportunistic security for HTTP
   URIs (as in [1]) do not count as "secure transports".

   [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption

I'm sure that's probably broken and needs fixing but some explicit
text would be good. (Nonetheless, since we've discussed it, I will
move to a Yes even if you don't add stuff for this.)

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

No, I don't think such a change would be needed. You only need
to re-define max-age as an offset from the time of reception.
For the current web that's close enough to the time of emission
that all's well. It'd only make a difference for a DTN-like web.
But, that last of course means that almost nobody cares, so I'll
stop now:-)

Cheers,
S.


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