[secdir] Secdir last call review of draft-sahib-451-new-protocol-elements-01

[Barry Leiba <[e-mail]>]

Reviewer: Barry Leiba
Review result: Has Issues

I've already commented on this before being assigned the SecDir review, but
I'll add further comment here.

Basically, I object to handling this as an AD-sponsored Informational document,
which updates a working group product that is Standards Track.  I also object
to complicating a protocol element that was intentionally devised as very
simple.

That said, I don't object to everything in the document, and if the 2119 key
words were removed we could salvage things.  Looking at the recommendations in
Section 4:

- I object to the first recommendation on the grounds that it makes no sense
that I can determine, and whatever sense I do try to make of it seems wrong. 
If the legal demand is "don't return any information about pangalactic
gargle-blasters (PGBs)," does that meet the specificity requirement for (1) the
Wikipedia page on PGBs, (2) an Amazon listing for a PGB for purchase, (3) a
blog post about "The "Hitchhiker's Guide to the Galaxy" that mentions
intergalactic drinks, (4) *any* web page that has the string "pangalactic
gargle-blaster" in it, regardless of the other content?  If the legal demand is
not to provide any content whatsoever to users outside the solar system, such
that every request from Alpha Centauri gets a 451, why should we not use 451
for that?  Please let's strike this recommendation.

- The second recommendation is simply not necessary: RFC 7725 is clear on this,
and if operators are doing otherwise there's no reason to think that a sentence
in an Informational document will change anything.  Let's please strike this
one as well.

- The third and fourth recommendations, and the link relation definition and
header that go with them, are benign enough: we can see whether they get
deployed or not.  If we removed the "SHOULD"s and made it clear that this is
suggested as a means to add more information, and is not part of the standard,
I'd not object to registering them and including the recommendations.

In Section 7.2, I suggest a change such as this:

OLD
   HTTP 451 is used as a response when the client requests a resource
   that's unavailable because of legal reasons.  Consequentially, there
   are potential privacy (and anonymity) ramifications if there is
   leakage of who accessed what resource.
NEW
   With any HTTP request, there are potential privacy and anonymity
   ramifications if there is leakage of who accessed what resource.
   HTTP 451 is used as a response when the client requests a resource
   that's unavailable because of legal reasons.  Consequentially, the
   privacy and anonymity ramifications may be even more significant.
END

I find Section 7.11 to be vague to the point of being content-free, and,
therefore, pointless.

In 7.14, the draft says, "Objective of this draft is to increase reliability by
making it clearer what a good HTTP 451 response looks like."  That looks like
marketing, and, to my eyes, looks wrong, as well... or, at least, if that's the
objective, I think the draft has failed here.  I'd strike that sentence.  (By
the way, in general it's good to avoid referring to a document as "this draft",
because that designation becomes obsolete if the draft becomes an RFC.  Better
to say "this document".)

In 7.16, there's nothing specific about the 451 response code here.  I guess
you could say, "All HTTP transactions are susceptible to leakage unless they
are protected by encryption, such as through the use of HTTPS."

--
Barry