Last Call Review of draft-ietf-httpbis-alt-svc-12
review-ietf-httpbis-alt-svc-12-secdir-lc-lonvick-2016-02-25-00
| Request | Review of | draft-ietf-httpbis-alt-svc |
|---|---|---|
| Requested revision | No specific revision (document currently at 14) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-02-24 | |
| Requested | 2016-02-11 | |
| Authors | Mark Nottingham , Patrick McManus , Julian Reschke | |
| Draft last updated | 2016-02-25 | |
| Completed reviews |
Genart Last Call review of -12
by
Francis Dupont
(diff)
Secdir Last Call review of -12 by Chris M. Lonvick (diff) |
|
| Assignment | Reviewer | Chris M. Lonvick |
| State | Completed | |
| Review |
review-ietf-httpbis-alt-svc-12-secdir-lc-lonvick-2016-02-25
|
|
| Reviewed revision | 12 (document currently at 14) | |
| Result | Has Nits | |
| Completed | 2016-02-25 |
review-ietf-httpbis-alt-svc-12-secdir-lc-lonvick-2016-02-25-00
Resending to get it to all the right people.
Hi,
I have reviewed this document as part of the security
directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of
the
security area directors. Document editors and WG chairs should
treat
these comments just like any other last call comments.
Overall, the document looks pretty good. It clearly spells out its
intent and the implementation. I believe it will be useful.
I would recommend some small edits which are more on the
subjective side. Please take these as mere suggestions and use
them, edit them, or ignore them as you see fit.
The term "safely ignore it" is used twice in the document. I would
prefer a more concrete directive for each. The first time it is
used is in the second paragraph of Section 4. In this case, the
term should be replaced with "MAY" as that is definitive per RFC
2119 for the protocol. The second case occurs in the following
paragraph:
The ALTSVC frame is intended for receipt by clients; a server that
receives an ALTSVC frame can safely ignore it.
I'd recommend changing that to:
The ALTSVC frame is intended for receipt by clients. A device acting
as a server MUST ignore it.
This advises what to do if a server receives the frame, but allows
some leeway if the device is simultaneously being used as a
client.
In Section 9.2, there is a paragraph that starts as follows:
Alternative services could be used to persist such an attack; for
example, an...
The whole thing is a bit of a run-on sentence so I'd recommend
that the semicolon be replaced with a period and a second sentence
started after that.
Each use of 'e.g.' should be followed by a comma. There seem to be
some that aren't.
Section 9.3 has the following two paragraphs:
For example, if an
"https://"
URI has a protocol advertised that does
not use some form of end-to-end encryption (most likely, TLS), it
violates the expectations for security that the URI scheme implies.
Therefore, clients cannot blindly use alternative services, but
instead evaluate the option(s) presented to assure that security
requirements and expectations (of specifications, implementations and
end users) are met.
This should either be one unified paragraph or two paragraphs expressing
different thoughts. My suggestion would be:
For example, if an
"https://"
URI has a protocol advertised that does
not use some form of end-to-end encryption (most likely TLS), it
violates the expectations for security that the URI scheme denotes.
Therefore, clients MUST NOT blindly use alternative services, but
instead SHOULD evaluate the option(s) presented and make a selection
that assures the security requirements and expectations of policy
provided by specifications, implementations, and end user desires.
There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a
sentence does not require that it be within parenthesis. Stick a comma in front
it it and move on. ;-) Y'all almost did that within the last paragraph of
Section 9.5 but didn't get it altogether right.
When the protocol does not explicitly carry the scheme (e.g., as is
usually the case for HTTP/1.1 over TLS, servers can mitigate this
risk by either assuming that all requests have an insecure context,
or by refraining from advertising alternative services for insecure
schemes (such as HTTP).
The first parenthetical is opened with a left parenthesis but closed with a
comma. I'd suggest using commas to open and close that. The second should just
be separated by a preceding comma.
Best regards,
Chris