[Uta] Fwd: Last Call: <draft-elie-nntp-tls-recommendations-01.txt> (Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)) to Proposed Standard

[Julien ÉLIE <[e-mail]>]

Hi all,

Last year, we spoke about a possible refresh of RFC 4642 (TLS with NNTP) 
to be consistent with the latest published RFCs about TLS, notably UTA 
BCP 195.
I based my work on RFC 7590 (TLS with XMPP).

In case you have any comments about the following document, that is now 
in Last Call stage, please tell.

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

Thanks beforehand for your review!



I have especially two questions for UTA (Appendix E):


1/    Should the following paragraph in Section 2.2.2 of [RFC4642]
       remain as-is or should it be modernized with another wording?
       (And which one?  or is it already done by the reference to
       [RFC7525]?)

 > Quoting [RFC4642]:
    Servers MUST be able to understand backwards-compatible TLS Client
    Hello messages (provided that client_version is TLS 1.0 or later),
    and clients MAY use backwards-compatible Client Hello messages.
    Neither clients nor servers are required to actually support Client
    Hello messages for anything other than TLS 1.0.  However, the TLS
    extension for Server Name Indication ("server_name") [TLS-EXT] SHOULD
    be implemented by all clients; it also SHOULD be implemented by any
    server implementing STARTTLS that is known by multiple names.
    (Otherwise, it is not possible for a server with several hostnames to
    present the correct certificate to the client.)



2/    Should the paragraphs in Section 5 of [RFC4642] dealing with how
       the client checks the server hostname and the binding between the
       identity of servers and the public keys presented be modernized?
       (Obsolete them in favour of [RFC6125] for instance?  or maybe
       [RFC7525] is enough as it also points to [RFC6125])

 > Quoting [RFC4642]:
    During the TLS negotiation, the client MUST check its understanding
    of the server hostname against the server's identity as presented in
    the server Certificate message, in order to prevent man-in-the-middle
    attacks.  Matching is performed according to these rules:

    -  The client MUST use the server hostname it used to open the
       connection (or the hostname specified in TLS "server_name"
       extension [TLS-EXT]) as the value to compare against the server
       name as expressed in the server certificate.  The client MUST NOT
       use any form of the server hostname derived from an insecure
       remote source (e.g., insecure DNS lookup).  CNAME canonicalization
       is not done.

    -  If a subjectAltName extension of type dNSName is present in the
       certificate, it SHOULD be used as the source of the server's
       identity.

    -  Matching is case-insensitive.

    -  A "*" wildcard character MAY be used as the left-most name
       component in the certificate.  For example, *.example.com would
       match a.example.com, foo.example.com, etc., but would not match
       example.com.

    -  If the certificate contains multiple names (e.g., more than one
       dNSName field), then a match with any one of the fields is
       considered acceptable.

    If the match fails, the client SHOULD either ask for explicit user
    confirmation or terminate the connection with a QUIT command and
    indicate the server's identity is suspect.

    Additionally, clients MUST verify the binding between the identity of
    the servers to which they connect and the public keys presented by
    those servers.  Clients SHOULD implement the algorithm in Section 6
    of [PKI-CERT] for general certificate validation, but MAY supplement
    that algorithm with other validation methods that achieve equivalent
    levels of verification (such as comparing the server certificate
    against a local store of already-verified certificates and identity
    bindings).


-- 
Julien ÉLIE

« Ça n'a été qu'un coup de glaive dans l'eau. » (Astérix)


-------- Message transféré --------
Sujet : Last Call: <draft-elie-nntp-tls-recommendations-01.txt> (Use of 
Transport Layer Security (TLS) in the Network News Transfer Protocol 
(NNTP)) to Proposed Standard
Date : Mon, 28 Nov 2016 08:45:30 -0800
De : The IESG
Pour : IETF-Announce


The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of Transport Layer Security (TLS) in the Network News Transfer
    Protocol (NNTP)'
   <draft-elie-nntp-tls-recommendations-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[e-mail] mailing lists by 2016-12-26. Exceptionally, comments may be
sent to [e-mail] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-elie-nntp-tls-recommendations/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-elie-nntp-tls-recommendations/ballot/


No IPR declarations have been submitted directly on this I-D.