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 <[email protected]> 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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
