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

Barry Leiba <barryleiba@computer.org> Sat, 14 July 2018 13:57 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A10130DBE; Sat, 14 Jul 2018 06:57:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: <secdir@ietf.org>
Cc: ietf@ietf.org, draft-sahib-451-new-protocol-elements.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153157663246.12737.5786220541781133621@ietfa.amsl.com>
Date: Sat, 14 Jul 2018 06:57:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/kkW23QFiOXIuft7ex2M7OK88wrw>
Subject: [secdir] Secdir last call review of draft-sahib-451-new-protocol-elements-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2018 13:57:13 -0000

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

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:

   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.
   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.

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."