[NNTP] Draft -00 for modernizing TLS usage with NNTP

Julien ÉLIE <julien@trigofacile.com> Sat, 23 July 2016 21:08 UTC

Return-Path: <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>
X-Original-To: ietfarch-nntpext-archive@ietfa.amsl.com
Delivered-To: ietfarch-nntpext-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534DD12B00A for <ietfarch-nntpext-archive@ietfa.amsl.com>; Sat, 23 Jul 2016 14:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 XPOsKX3A28bF for <ietfarch-nntpext-archive@ietfa.amsl.com>; Sat, 23 Jul 2016 14:08:01 -0700 (PDT)
Received: from hope.eyrie.org (hope.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3535]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183C012D0B0 for <nntpext-archive@ietf.org>; Sat, 23 Jul 2016 14:08:00 -0700 (PDT)
Received: from hope.eyrie.org (localhost [IPv6:::1]) by hope.eyrie.org (Postfix) with ESMTP id DA93767DB0 for <nntpext-archive@ietf.org>; Sat, 23 Jul 2016 14:07:59 -0700 (PDT)
X-Original-To: ietf-nntp@lists.eyrie.org
Delivered-To: ietf-nntp@lists.eyrie.org
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by hope.eyrie.org (Postfix) with ESMTPS id A332567D29 for <ietf-nntp@lists.eyrie.org>; Sat, 23 Jul 2016 14:07:57 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d12 with ME id NM7v1t00J17Lgi403M7wzy; Sat, 23 Jul 2016 23:07:56 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg==
X-ME-Date: Sat, 23 Jul 2016 23:07:56 +0200
X-ME-IP: 92.170.5.52
To: ietf-nntp@lists.eyrie.org
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <5e236b2f-fe77-07be-a9aa-4771df12cbcd@trigofacile.com>
Date: Sat, 23 Jul 2016 23:07:55 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [NNTP] Draft -00 for modernizing TLS usage with NNTP
X-BeenThere: ietf-nntp@lists.eyrie.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: NNTP protocol discussion <ietf-nntp.lists.eyrie.org>
List-Unsubscribe: <https://lists.eyrie.org/mailman/options/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=unsubscribe>
List-Archive: <https://lists.eyrie.org/pipermail/ietf-nntp/>
List-Post: <mailto:ietf-nntp@lists.eyrie.org>
List-Help: <mailto:ietf-nntp-request@lists.eyrie.org?subject=help>
List-Subscribe: <https://lists.eyrie.org/mailman/listinfo/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=subscribe>
Errors-To: ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org
Sender: ietf-nntp <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>

Hi all,

I've just taken the time to finalize a first version of an 
Internet-Draft that could update RFC 4642 (use of TLS with NNTP):

     https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-00

Basically, it adds TLS best current practices to RFC 4642 (disabling 
TLS-level compression, preferring strict TLS to port 563, removing RC4 
cipher suites from mandatory-to-implement cipher suites) and also gives 
several kinds of recommendations (in Section 2).


Thanks beforehand for your comments.
Do not hesitate to tell if something looks wrong, and also what you 
think about the issues to address in Appendix D.  Especially:

    o  Section 3.2 of [RFC7525] applied to NNTP adds the following
       requirement:  a client SHOULD attempt to negotiate TLS even if the
       STARTTLS capability label is not advertised by the news server.
       The goal is to help prevent SSL Stripping.  Yet, an attacker who
       can strip STARTTLS from the capability list could easily ensure
       that 502 is answered to that command.  So, should we all the same
       keep that requirement for NNTP?  (I would suggest not to keep it.)

    o  Regarding peering between mode-switching news servers, should
       something specific be added?  (e.g., as strict TLS is the
       preferred way to negotiate TLS, innfeed would connect to port 563
       of a news server, and innd would also listen on port 563.  Or
       should we ask the registration of a new port for that purpose,
       NNSP over TLS, like port 433 already dedicated to NNSP?  Or should
       we recommend the use of stunnel with TCP wrappers, or an
       equivalent mechanism, in case using a separate port is not
       possible?)

-- 
Julien ÉLIE

« – Tu n'as rien remarqué d'étrange chez cet Arverne ?
   – Oui, son accent. » (Astérix)