Re: [websec] Gen-art LC review of draft-ietf-websec-key-pinning-19

[Ryan Sleevi <[e-mail]>]

On Sat, Aug 30, 2014 at 11:42 AM, Elwyn Davies <[e-mail]>
wrote:

> Hi, Chris.
>
> A couple of remaining points and a couple of nits/queries in the fixes.
>
> I have deleted the items that we are agreed on below and added comments in
> line.
>
> New nits:
> s2.6, next to last para: s/previous/previously/
>
> s4, lasta para:
>
>> and indeed MUST pin to issuers not in the chain
>>
>
> Is this a requirements MUST?  The protocol will be quite happy and
> implementers can't (at least I don't think) they can check if the host
> leaves it out.  This is operational advice (admittedly highly relevant) but
> still advice I think.
>
> On 25/08/14 21:23, Chris Palmer wrote:
>
>> On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <[e-mail]>
>> wrote:
>>
>>  <<snip>>
>
>  Ok.  Accepting that the host is expected normally to send the headers on
>>> all
>>> responses, when SHOULD it not send the headers? (from the previous
>>> comments
>>> a server that knows it is not multiplexed might be a candidate - or if it
>>> knows it has already responded on this connection?)
>>>
>>
>> I think it's easiest and simplest for servers to simply always send the
>> headers.
>>
>>
> Having thought about this a bit, I don't think this text fully reflects
> what is going on in the server.  If I understand correctly, we have:
> - Server has a policy that it wants to be pinned if it can be (presumably
> this ought to be configurable in the server).
> - When a client sends a request over a new secure connection and the
> policy says 'be pinned', the server sends back pinning header(s) in the
> response.
> - Thereafter, it MAY for simplicity send pinning headers in all subsequent
> responses on the connection. Alternatively it can do something intelligent
> and not bother sending the headers if it is the same connection - but of
> course this probably means a layer violation.
>
> Thought: Does it make any difference if the client doesn't accept the pin?
> Should success or failure be logged?  Should the host always keep sending
> the headers if the client didn't accept the pin on the first
> exchange (is this a possible symptom of a MITM?)?
>
> Suggestion:
> OLD:
> 2.2.1.  HTTP-over-Secure-Transport Request Type
>
>    When replying to an HTTP request that was conveyed over a secure
>    transport, a Pinned Host SHOULD include in its response exactly one
>    PKP header field, exactly one PKP-RO header field, or one of each.
>
> NEW:
> 2.2.1.  HTTP-over-Secure-Transport Request Type
>
>    If a host has a policy of becoming a Pinned Host whenever possible,
>    then on replying to an initial HTTP request that was conveyed over a
>    secure transport, a host intending to become Pinned Host includes in
>    its response exactly one PKP header field, exactly one PKP-RO header
>    field, or one of each.  The host MAY include the same header(s)
>    with any subsequent responses using the same connection.
>
>
>
Just to cycle back on modifications, I've opted not to make this
modification, as it violates the independence of HTTP Request/Responses.
That is, each Request/Response over a given Connection is meant to be
treated in isolation.

The language proposed, while possible, also misses out on edge cases like
HTTP pipelining (and figuring out when pinning takes effect) or the
semantics of HTTP/2.0, which allows connection pooling (
https://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.1.1 )


> <<snip>>
>
>  Also there may be some of the questions in s8.3.1 of RFC 7231 that need
>>>>>> specific answers.
>>>>>>
>>>>>
>>> There are still some of the questions that ought to be explicitly
>>> answered.
>>>
>>
>> To me, the only questions that might not have obvious answers are:
>>
>>     o  Whether the header field is useful or allowable in trailers (see
>>        Section 4.1 of [RFC7230]).
>>
>> Surely not? For the same reason we don't want it in meta http-equiv.
>>
>
I'm ambivalent about this. I treat headers - leading or trailing - as part
of the security boundary of a server. I'm not keen on violating any header
semantics here.


>
>>     o  Whether the header field ought to be preserved across redirects.
>>
>
I don't see any problem here, because it's a Response header, not a Request
header.


>
>> Surely not?
>>
>> Any others?
>>
>
> The point was that I guess you ought to explicitly say "not" in each case.
>
>
>>  <<snip>>
>
>  Changes visible at
>> https://code.google.com/p/key-pinning-draft/source/list. I won't push
>> a version 21 until I've gone through the rest of the incoming email.
>>
>> Thank you!
>>
>>  Cheers,
> Elwyn
>