[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.55.220.193 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 10.140.39.52 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. References: 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 extension. 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 listed. -- 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 Section. 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 active. 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 algorithm. I don't understand what this is saying at all. Different from what? Can you clarify this? -- Barry
- [secdir] Secdir review of draft-murchison-nntp-co… Barry Leiba
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Barry Leiba
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Barry Leiba
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE
- Re: [secdir] Secdir review of draft-murchison-nnt… Ken Murchison
- Re: [secdir] Secdir review of draft-murchison-nnt… Michael Bäuerle
- Re: [secdir] Secdir review of draft-murchison-nnt… Alexey Melnikov
- Re: [secdir] Secdir review of draft-murchison-nnt… Julien ÉLIE