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

[Elwyn Davies <[e-mail]>]

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.


<<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.
>
>     o  Whether the header field ought to be preserved across redirects.
>
> 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