[secdir] Secdir review of draft-murchison-nntp-compress-05

Barry Leiba <barryleiba@computer.org> Wed, 21 September 2016 13:27 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 304E612B2C1; Wed, 21 Sep 2016 06:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 59Xx5Y3Gc1Q0; Wed, 21 Sep 2016 06:27:01 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E0412B2B6; Wed, 21 Sep 2016 06:25:59 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id n185so45092585qke.1; Wed, 21 Sep 2016 06:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=VdTo2W35pmNjdjWuK0Fp5auoR1Yo+JGL+/z9J17ltYI=; b=Jgqb3RtMNm8E3gFz7a2BMfoQPPDTmZrTb3yGUMj6QYzzqULfGIz4+xuPVcKkBbUcto es34jsAAjLe0Ae0rg/XVQqb4YCHxGzf1GKuHt8MmJyyn2ZsCbi3DsPW/5XrnJKh5NB+U /nFmT4icj26z8opTgQFEywdaLXtFivwvlCAkstljJUbkKe5txeQ5vHSroMnA4aUXrbN2 ELOPSHpVSIJ+4/H2vDqP0lrG4/kVNVPhR2Ik/6shjYxAmPDyyR7L7Kh3QZQYtEGXxta9 vuV2m8ZkhsN81eo7MwTwkkJkBVOLHztqGQYgj9m6Je63E0m1olKuzdhhdumJNdBDZyIz N9rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=VdTo2W35pmNjdjWuK0Fp5auoR1Yo+JGL+/z9J17ltYI=; b=jgnAo+LT7pXMy+xcAJBfp1pa0QG45z1dgIPabMN6aoUhZg7Pqw24rJgOwYuzHXuxDS RYiZdxmPXGnhI/WqdNqKWsw0ne0JMxH33g6rVoxgfXkZHrwh912PMb046aVMGFx8jroB KLm6CgOEx8VImRotVegMnR8Wt8OZS0SFKLpO1keXD4p0gMdKunHiuitgTq1I0NjZKm4L XKfHwGn2Dfn1QMMCTJEU8olMYOBJVX17BwytVsp86fwJa9jC3zBMKwyiocrUiZJtfIGb OXODsQnzFiqUHY3JF6Oa+015n0M3Lund+uPo3+of0Wj3NHNJFNvzBdsOUkYheeXllNN+ 8VUQ==
X-Gm-Message-State: AE9vXwO70INX4mjPX0TpoecM9wha/qQHnXhJyOKdcDKu8YT2dAGSeyLDio3HXSSlwboiNZWrwwP4aytglUEqLw==
X-Received: by with SMTP id v184mr31799393qki.303.1474464358268; Wed, 21 Sep 2016 06:25:58 -0700 (PDT)
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by with HTTP; Wed, 21 Sep 2016 06:25:57 -0700 (PDT)
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 21 Sep 2016 14:25:57 +0100
X-Google-Sender-Auth: vdI3F-mteAiQr9lImUjl49tJIIA
Message-ID: <CALaySJ+mJdorTkygsZ==Bja+0ZmavTkq2kC33QJ67LeM34K=Ng@mail.gmail.com>
To: draft-murchison-nntp-compress.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_iqmAuXr6EDYrthQFqrCAEr5_Yg>
Cc: IESG <iesg@ietf.org>, secdir@ietf.org
Subject: [secdir] Secdir review of draft-murchison-nntp-compress-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Wed, 21 Sep 2016 13:27:03 -0000

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.

There are no major issues here, but there are a number of things I
think need to be addressed before this document is ready.

RFC 1951 (DEFLATE) MUST be implemented with this, so it needs to be a
normative reference.

-- Section 2.1 --

   This document defines one
   compression algorithm: DEFLATE.  This algorithm is mandatory to
   implement and MUST be supported in order to advertise the COMPRESS

Just to be clear and specific, I suggest changing the second sentence
to say "and MUST be supported and listed in the advertisement of the
COMPRESS extension."

-- Section 2.2.2 --

   In order to help mitigate leaking authentication credentials via for
   instance a CRIME attack [CRIME], authentication SHOULD NOT be
   attempted when a compression layer is active.  Consequently, a server
   SHOULD NOT return any arguments with the AUTHINFO capability label
   (or SHOULD NOT advertise it at all) in response to a CAPABILITIES
   command received from an unauthenticated client after a compression
   layer is active, and such a client SHOULD NOT attempt to utilize any
   AUTHINFO [RFC4643] commands.  It implies that a server SHOULD reply
   with a 502 response code if a syntactically valid AUTHINFO command is
   received while a compression layer is already active.

Why are these SHOULD, and not MUST?  Under what conditions would it be
necessary or reasonable for an implementation not to abide by these,
and what considerations need to be considered when making that
determination?  (And this is also directly referred to in Section 6.)

   When compression is active and either the client or the server
   receives invalid or corrupted compressed data, the receiving end
   SHOULD immediately close the connection.  (Then the sending end will
   in turn do the same.)

Same question.

-- Section 2.3 --

At the end of the first example, it would be useful to add another
CAPABILITIES command to show that COMPRESS DEFLATE is no longer

-- Section 5 --

   This section contains a list of each new response code defined in
   this document and indicates whether it is multi-line, which commands
   can generate it, what arguments it has, and what its meaning is.

This is a total nit, but this sentence seems odd when there's only one
new code (there's also nothing that says whether it is or isn't
multi-line).  I suggest, instead, "The following new response code is
defined in this document:".

-- Section 6 --

   NNTP commands other than AUTHINFO are not believed to divulgate
   confidential information

Qu'est que c'est "divulgate"?  Perhaps you mean "divulge", unless
you're Shakespeare.

   In case confidential articles are accessed in private
   newsgroups, special care is needed: implementations SHOULD NOT
   compress confidential data together with public data when a security
   layer is active, for the same reasons as mentioned above in this

Sorry: it is not clear to me what reasons those are; can you be
specific here?  And why SHOULD, and not MUST?

   Additionally, implementations MAY ensure that the contents of two
   distinct confidential articles are not compressed together.

Of course they MAY, but what's the point of saying that.  I think
you'd be much better off skipping the 2119 key word here, and instead
say something about why it might be good to do this: what's the
advantage?  Something like, "Additionally, implementations would do
well to ensure that the contents of two distinct confidential articles
are not compressed together, because [of this advantage]."

   Future extensions to NNTP that define commands conveying confidential
   data SHOULD ensure to state that these confidential data SHOULD NOT
   be compressed together with public data when a security layer is

I guess this is related the the paragraph I quoted immediately above,
so the question is the same.

-- Section 7.1 --

   Any name that conforms to the syntax of an NNTP compression algorithm
   name (Section 4.3) can be used.

It would be useful here, for IANA's benefit, to specifically highlight
that letters in algorithm names are always upper case.

   However, the name of a registered
   NNTP compression algorithm MUST NOT begin with "X".

   To avoid the risk of a clash with a future registered NNTP
   compression algorithm, the names of private compression algorithms
   SHOULD begin with "X-".

This was discussed in response to another review, and I understand the
"X-" stuff will be removed.  Thanks.

   If it does not implement the compression
   algorithm as specified, it MUST NOT list its registered name in the
   arguments list of the COMPRESS capability label.  In that case, it
   MAY, but SHOULD NOT, provide a private algorithm (not listed, or
   listed with a different name) that implements the compression
   algorithm differently.

Oy.  This really sounds convoluted to me, and the "MAY, but SHOULD
NOT" is a direct contradiction.

I think what you're trying to say here is that if you list a
registered algorithm, it MUST be properly implemented according to the
relevant spec.  Got that.  Now, what about including unregistered
algorithms?  Do you want to say that you MAY include unregistered
algorithms?  Do you want to say that you SHOULD NOT include any?  Why
not, and why might you decide to do that anyway?  What are the
interoperability issues with respect to unregistered algorithms?

   A server MUST NOT send different response codes to COMPRESS in
   response to the availability or use of a private compression

I don't understand what this is saying at all.  Different from what?
Can you clarify this?