I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-websec-strict-transport-sec-11
Reviewer: Ben Campbell
Review Date: 2012-07-24
IETF LC End Date: 2012-07-25
Summary: This draft is almost ready for publication as a proposed standard, but
there are a few issues that should be considered first.
*** Major issues:
None
*** Minor issues:
-- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
should be explicitly flagged and mentioned in the abstract.
-- I did not find any guidance on how to handle UAs that do not understand this
extension. I don't know if this needs to be normative, but the draft should at
least mention the possibility and implications.
-- How should a UA handle potential conflicts between a the policy record that
includes the includeSubdomain, and any records for subdomains that might have
different parameters?
-- section 6.1:
The draft mentions that directives may be extended, but defers creation of an
IANA registry to the time of first extension. IANA registries are not
expensive; I suggest it be created now. If there's a good reason not to, then
the draft should still address the specification policy for extensions.
Also, do you expect that some future directive might need to have a
"required-to-understand" status? Given that this is a security-affecting
extension, it seems likely. If so, then the mechanism for expressing that needs
to be defined in this draft.
-- section 7.2:
Am I correct to assume that the server must never just serve the content over a
non-secure connection? If so, it would be helpful to mention that, maybe even
normatively.
-- section 8.4:
Does this imply a duty for compliant UAs to check for revocation one way or
another?
*** Nits/editorial comments:
-- idnits reports an uncited reference:
== Unused Reference: 'RFC6376' is defined on line 1709, but no explicit
reference was found in the text
-- section 1.2:
The description of indented notes is almost precisely the opposite of how they
are described in the RFC editor's style guide. It describes them as
"parenthetical" notes, which is how experienced RFC readers are likely to
perceive them. While it doesn't say so explicitly, I think putting normative
text in parenthetical notes should be avoided. If these are intended to be
taken more strongly than that (and by the description, I take it they should be
taken more strongly than the surrounding text), then I suggest choosing a
stronger prefix than "NOTE:"
-- section 7:
Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for
SSL3? Also, that's a long expired draft, even for an informational reference.
-- section 8.2, paragraph 5 (first non-numbered paragraph after numbered list)
To be pedantic, this could be taken to mean a congruent match only applies if
the includeSubdomains flag is not present. I assume it's intended to apply
whether or not the flag is present.
-- section 12 and subsections:
I was surprised to see more apparently normative material after the
non-normative guidance sections. I think it would improve the organization to
put this closer to the normative rules for UAs.
-- section 14.1, 4th paragraph (first non-bulleted paragraph following bullet
list)
This issue is only true for proxies that act as a TLS MiTM, right? Would
proxies that tunnel TLS via the CONNECT method have this issue?
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art