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

[Barry Leiba <[e-mail]>]

Hi, Stephen.  Can you retrieve context and see if version -21
resolves your issues (and restart the discussion if not)?  Thanks.

Barry

On Mon, Aug 25, 2014 at 6:06 AM, Stephen Farrell
<[e-mail]> wrote:
>
> 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.
>>
>