Subject: [websec] Review of draft-ietf-websec-key-pinning-06

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Jul 2013 18:11:54 +0100

In 2.1, 1st para: use of SHOULD is not needed. This is already an 
extension. What is the point of violating the SHOULD? It seems to be the 
same as not supporting the extension.

End of section 2.1: base-64 needs a Normative reference.

2.1.3: next to the last paragraph: "MAY fail to report" is not a proper 
use of RFC 2119 keyword, as this is not an implementation choice. Just 
use lowercase "may" here.

sha-1 and sha-256 need Normative references.

In 2.5: the 3rd para from the end: how is this different from the 4th 
para? It seems to specify a weaker requirement.

Typo: max.age

JSON (Section 3) needs a Normative reference.

Section 5 (IANA) contradicts section 2.1. So actually there are IANA 
Considerations.

You should mark Section 8 as requiring removal by RFC-Editor, as this 
section is not useful in the final document (RFC).

---

From: Chris Palmer <[email-masked]>
Date: Mon, 8 Jul 2013 16:29:48 -0700

Thanks, Alexey! I will soon upload a version -07 that addresses most
of your points and which also adds a Privacy Considerations section as
requested by previous commenters. Notes and questions below:

On Mon, Jul 8, 2013 at 10:11 AM, Alexey Melnikov
<[email-masked]> wrote:

> In 2.1, 1st para: use of SHOULD is not needed. This is already an extension.
> What is the point of violating the SHOULD? It seems to be the same as not
> supporting the extension.

Lowercased to "should".

> End of section 2.1: base-64 needs a Normative reference.

Added and cited.

> 2.1.3: next to the last paragraph: "MAY fail to report" is not a proper use
> of RFC 2119 keyword, as this is not an implementation choice. Just use
> lowercase "may" here.

Done.

> sha-1 and sha-256 need Normative references.

Added and cited.

> In 2.5: the 3rd para from the end: how is this different from the 4th para?
> It seems to specify a weaker requirement.

Can you say which paragraphs explicitly? I'm having a hard time
figuring out which ones you mean. Thanks.

> Typo: max.age

Fixed.

> JSON (Section 3) needs a Normative reference.

Added and cited.

> Section 5 (IANA) contradicts section 2.1. So actually there are IANA

Added a comment in Section 5 to that effect.

> section is not useful in the final document (RFC).

At least some RFCs do have Acknowledgements sections?

Is there a standard way of telling the RFC-Editor to remove the section?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Jul 2013 04:57:15 +0000

> figuring out which ones you mean. Thanks.

3rd Para: "If the Public-Key-Pins response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host."

4th Para: "The UA MUST ignore Public-Key-Pins response header fields received on connections that do not meet the first criterion."

> Is there a standard way of telling the RFC-Editor to remove the section?

The standard way is to add a sentence like:
[RFC EDITOR: PLEASE REMOVE THIS SECTION]

And don't worry, just before the RFC is published, you get to review that the RFC editor made all the right changes.

And I think Alexey meant section 9 ("What's changed") rather than section 8. RFCs do have acknowledgement sections.

Hope this helps

Yoav

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 9 Jul 2013 09:09:52 +0100

> And I think Alexey meant section 9 ("What's changed")

Oh yes, you are correct.

> rather than section 8. RFCs do have acknowledgement sections.

---

From: Chris Palmer <[email-masked]>
Date: Wed, 10 Jul 2013 16:01:02 -0700

> 4th Para: "The UA MUST ignore Public-Key-Pins response header fields received on connections that do not meet the first criterion."

Oh, right. Yes, I think we can just delete that 4th paragraph. Done in
an upcoming -08.

Done.

Thanks!