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

[Julien ÉLIE]

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 at 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
>