[Uta] Using TLS with NNTP

Julien ÉLIE <julien@trigofacile.com> Mon, 02 November 2015 10:12 UTC

Return-Path: <julien@trigofacile.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3071A1A6E for <uta@ietfa.amsl.com>; Mon, 2 Nov 2015 02:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 LBPccfV-ou3u for <uta@ietfa.amsl.com>; Mon, 2 Nov 2015 02:12:06 -0800 (PST)
Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) by ietfa.amsl.com (Postfix) with ESMTP id 44B021A07BC for <uta@ietf.org>; Mon, 2 Nov 2015 02:12:06 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 364A560096 for <uta@ietf.org>; Mon, 2 Nov 2015 11:12:05 +0100 (CET)
Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZrYpJxPqwTt for <uta@ietf.org>; Mon, 2 Nov 2015 11:12:05 +0100 (CET)
Received: from macbook-pro-de-julien-elie.home (AAubervilliers-651-1-146-112.w86-212.abo.wanadoo.fr [86.212.129.112]) by denver.dinauz.org (Postfix) with ESMTPSA id 0DF366008B for <uta@ietf.org>; Mon, 2 Nov 2015 11:12:05 +0100 (CET)
To: uta@ietf.org
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <563736F4.3070403@trigofacile.com>
Date: Mon, 02 Nov 2015 11:12:04 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/XIg-PFlCbg0CUJpZDv2NXjPB0GE>
Subject: [Uta] Using TLS with NNTP
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 10:12:10 -0000

Hi all,

Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there 
has been a discrepancy with the requirements of Section 5 of RFC 4642 
"Using Transport Layer Security (TLS) with Network News Transfer 
Protocol (NNTP)":

    NNTP client and server implementations MUST implement the
    TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
    important, as it assures that any two compliant implementations can
    be configured to interoperate.  All other cipher suites are OPTIONAL.



Another point is the fact that TLS 1.3 will remove support for 
compression.  The NNTP protocol is currently relying on that feature of 
TLS, as we can see in the abstract and the description of the STARTTLS 
command in RFC 4642:

    The STARTTLS command is usually used to initiate session security,
    although it can also be used for client and/or server certificate
    authentication and/or data compression.



A huge thread of more than a thousand messages has just been held in the 
TLS IETF working group. The chairs agreed to remove compression from TLS 
1.3:
     https://www.ietf.org/mail-archive/web/tls/current/msg17941.html

Basically, it is not the role of a security layer to provide a facility 
(compression) that is known to cause security issues (CRIME attack for 
instance).
If compression with TLS is wanted for NNTP, then clients and servers 
will have to use TLS 1.2 (or more ancient).




I was advised in the TLS mailing-list to contact the UTA WG.  (The NNTP 
WG is no longer an active IETF WG.)

The questions are:

- what move should be done about RFC 4642?
The good news is that Stephen Farrell, an IETF/IESG chairman, is willing 
to shepherd us on refreshing RFC 4642.  We have to decide the best move 
to do between a new RFC that obsoletes RFC 4642 or a short RFC that 
updates RFC 4242.
     http://www.ietf.org/mail-archive/web/tls/current/msg17562.html

- what should we say in that refresh?
An idea is that we could just refer to RFC 7525 (Recommendations for 
Secure Use of Transport Layer Security (TLS) and Datagram Transport 
Layer Security (DTLS)), that is a Best Current Practice:
     https://tools.ietf.org/html/bcp195

- do you see other things that should be improved at the same time in 
RFC 4642?

- as for compression, there is a draft for a COMPRESS command:
     http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html
Is it the right move to do for Applications that are currently relying 
on the compression provided by TLS?




P.-S. : Maybe in the wiki of UTA, the NNTP protocol could be mentioned :)
     http://trac.tools.ietf.org/wg/uta/trac/wiki


Thanks beforehand,

-- 
Julien ÉLIE

« Aut bibas aut abeas. »