[NNTP] Fwd: New Version Notification for draft-elie-nntp-tls-recommendations-03.txt

Julien ÉLIE <julien@trigofacile.com> Tue, 27 December 2016 21:03 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 CF325129706 for <ietfarch-nntpext-archive@ietfa.amsl.com>; Tue, 27 Dec 2016 13:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level:
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-3.1] 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 W1Ra5Qpbfwgo for <ietfarch-nntpext-archive@ietfa.amsl.com>; Tue, 27 Dec 2016 13:03:33 -0800 (PST)
Received: from hope.eyrie.org (hope.eyrie.org [166.84.7.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0D4128B38 for <nntpext-archive@ietf.org>; Tue, 27 Dec 2016 13:03:32 -0800 (PST)
Received: from hope.eyrie.org (localhost [IPv6:::1]) by hope.eyrie.org (Postfix) with ESMTP id CB44668255 for <nntpext-archive@ietf.org>; Tue, 27 Dec 2016 13:03:31 -0800 (PST)
X-Original-To: ietf-nntp@lists.eyrie.org
Delivered-To: ietf-nntp@lists.eyrie.org
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by hope.eyrie.org (Postfix) with ESMTPS id BDEB967ECA for <ietf-nntp@lists.eyrie.org>; Tue, 27 Dec 2016 13:03:29 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d09 with ME id R93T1u00U17Lgi40393TVR; Tue, 27 Dec 2016 22:03:28 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Tue, 27 Dec 2016 22:03:28 +0100
X-ME-IP: 92.170.5.52
References: <3c9c41a7-f2e1-c1a3-b5e3-b3ca19c2c494@trigofacile.com>
To: ietf-nntp@lists.eyrie.org
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
X-Forwarded-Message-Id: <3c9c41a7-f2e1-c1a3-b5e3-b3ca19c2c494@trigofacile.com>
Message-ID: <8198e2ed-1083-e94d-1daf-abedd16817a8@trigofacile.com>
Date: Tue, 27 Dec 2016 22:03:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <3c9c41a7-f2e1-c1a3-b5e3-b3ca19c2c494@trigofacile.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [NNTP] Fwd: New Version Notification for draft-elie-nntp-tls-recommendations-03.txt
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,

Last Call has ended for the draft updating RFC 4642 (use of TLS in 
NNTP).  The current text is here:
 
https://www.ietf.org/internet-drafts/draft-elie-nntp-tls-recommendations-03.txt

As usual, if you have any remark, please tell.


The main change is the addition of RFC 6125 as document to follow.  I've 
received valuable private input from Peter Saint-Andre about the right 
wording to use for the new text.


    o  NNTP implementations and deployments MUST follow the rules and
       guidelines defined in [RFC6125] and [RFC5280] for hostname
       validation and certificate verification.  Part of Section 5 of
       [RFC4642] is therefore rationalized in favour of following those
       two documents.

    The text between "During the TLS negotiation" and "identity
    bindings)." in Section 5 of [RFC4642] is replaced with the following
    text:

       During TLS negotiation, the client MUST verify the server's
       identity in order to prevent man-in-the-middle attacks.  The
       client MUST follow the rules and guidelines defined in [RFC6125],
       where the reference identifier MUST be the server hostname that
       the client used to open the connection (or the hostname specified
       in the TLS "server_name" extension [RFC6066]).  The following
       NNTP-specific consideration applies: DNS domain names in server
       certificates MAY contain the wildcard character "*" as the
       complete left-most label within the identifier.

       If the match fails, the client MUST follow the recommendations in
       Section 6.6 of [RFC6125] regarding certificate pinning and
       fallback.

       Beyond server identity checking, clients also MUST apply the
       procedures specified in [RFC5280] for general certificate
       validation (e.g., certificate integrity, signing, and path
       validation).




Changes since -02

    o  Use (and define) the "implicit TLS" terminology instead of "strict
       TLS".  The language in [RFC7525] is unfortunate since "strict TLS"
       is not clearly defined in that document, and the name suggests
       that it is an alternative to "opportunistic TLS", rather than an
       alternative to STARTTLS.  While STARTTLS is often used
       opportunistically, that is not always the case.

    o  Mention SSL Stripping in Section 3.6 with a reference to
       Section 2.1 of [RFC7457] because the intent of the related task
       may not have been clear enough.  Reported by Matija Nalis.

    o  Add Section 3.4 about how to prevent SSL stripping, notably by an
       attempt to negotiate TLS even if STARTTLS is not advertised, when
       implicit TLS is not used.

    o  Strengthen the requirements on hostname validation and certificate
       verification, by referencing [RFC6125] and [RFC5280].

    o  Ask IANA to add this document to the NNTP capabilily labels
       registry.

    o  Reference the security considerations of [RFC6125].

    o  Mention informative and normative references to add to [RFC4642].


-- 
Julien ÉLIE

« I had some words with my wife, and she had some paragraphs with
   me. » (Sigmund Freud)


Le 26/12/2016 à 15:41, internet-drafts@ietf.org a écrit :
>
> A new version of I-D, draft-elie-nntp-tls-recommendations-03.txt
> has been successfully submitted by Julien Élie and posted to the
> IETF repository.
>
> Name:		draft-elie-nntp-tls-recommendations
> Revision:	03
> Title:		Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)
> Document date:	2016-12-26
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-elie-nntp-tls-recommendations-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-elie-nntp-tls-recommendations/
> Htmlized:       https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-elie-nntp-tls-recommendations-03
>
> Abstract:
>    This document provides recommendations for improving the security of
>    the Network News Transfer Protocol (NNTP) when using Transport Layer
>    Security (TLS).  It modernizes the NNTP usage of TLS to be consistent
>    with TLS best current practices.  If approved, this document updates
>    RFC 4642.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>