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

[Chris Palmer <[e-mail]>]

On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <[e-mail]> wrote:

>>>> s2.1.1: I'm not sure if this could be an issue.. should a maximum
>>>> possible value for max_age
>>>> be specified to avoid UA's being cluttered up with old Pins - this might
>>>> possible be a DoS
>>>> attack vehicle but I am not sure (yet) if it could be. OK.. so s2.3.3
>>>> talks about limits.
>>>> A pointer to this discussion would be useful here
>
> A pointer to the discussion in s2.3.3 would still help.

Added.

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

>>>> s2.3.1/s2.4: S2.4 states that hash algorithms might be deprecated in
>>>> future.  Presumably a
>>>> deprecated algorithm should be treated as an unrecognized directive or
>>>> some such to avoid
>>>> downgrade attacks.  Probably worth being explicit about this.  Also this
>>>> is potentially
>>>> incompatible with the statement that 'UAs MUST recognize "sha256"' (Para
>>>> 3 of s2.4).
>>>> This results in a potential downgrade attack when and if SHA256 is
>>>> deemed to be no longer
>>>> cryptographically effective. I think this statement can be removed as
>>>> presently a UA
>>>> has no other option if it is to implement the specification.
>
> Not addressed as yet.  At least the statement in s2.4 needs to be removed.

Removed.

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

> One extra nit:
> s2, para after bullets: s/reistry/registry/

Fixed.

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!