On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <[email protected]> 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!
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
