Hi, FYI, I'll take into account for the revised version of draft-elie-nntp-tls-recommendations the comment Viktor gave in the UTA mailing-list. The terminology for "TLS negotiation immediately upon connection on a separate port" is not consistent between RFCs. RFC 7525 uses "strict TLS" (and unfortunately does not define the term). RFC 7672 uses "mandatory TLS". draft-ietf-uta-email-deep uses "implicit TLS". As I believe "implicit TLS" is the most accurate wording, I'll also use that term for draft-elie-nntp-tls-recommendations. -- Julien ÉLIE -------- Message transféré -------- Sujet : Re: [Uta] draft-ietf-uta-email-deep-05: wording about strict vs implicit TLS Date : Thu, 22 Dec 2016 17:07:07 +0100 De : Julien ÉLIE <julien@xxxxxxxxxxxxxxx> Organisation : TrigoFACILE -- http://www.trigofacile.com/ Pour : uta@xxxxxxxx Hi Viktor, >> draft-ietf-uta-email-deep-05 defines "Implicit TLS" in Section 4: >> 'amechanism where TLS is negotiated immediately at connection start on a >> separate port (referred to in this document as "Implicit TLS")' > > This choice of language is sensible, since the use of TLS is implicit > in the (choice of) transport endpoint, rather than explicitly negotiated > via STARTTLS. > >> whereas published RFC 7525 uses the terminology "strict TLS". It is the title of >> Section 3.2, which mentions 'a choice between strict TLS configuration and dynamic >> upgrade from unencrypted to TLS-protected traffic (such as STARTTLS)'. > > While the language in 7525 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. While RFC 7672 calls this "mandatory TLS", I would > expect "strict" and "mandatory" to be synonymous. I perfectly understand your arguments, and I agree with you. Shouldn't an erratum be added to RFC 7525 so as to at least add a definition of "strict TLS"? It is indeed missing! I've updated the wording in draft-elie-nntp-tls-recommendations so as to use "implicit TLS" like draft-ietf-uta-email-deep. In particular, this document updates [RFC4642] by specifying that NNTP implementations and deployments MUST follow the best current practices documented in the "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. This includes stronger recommendations regarding SSL/TLS protocol versions, fallback to lower versions, TLS negotiation immediately upon connection on a separate port (referred to in this document as "implicit TLS"), TLS-level compression, TLS session resumption, cipher suites, public key lengths, forward secrecy, and other aspects of using TLS with NNTP. [...] o NNTP implementations and deployments SHOULD prefer implicit TLS and therefore use strict TLS configuration (Section 3.2 of [RFC7525]), that is to say they SHOULD use a port dedicated to NNTP over TLS, and begin the TLS negotiation immediately upon connection (contrary to a dynamic upgrade from unencrypted to TLS- protected traffic via the use of the STARTTLS command, as Section 1 of [RFC4642] was encouraging). For the same reasons, transposed to NNTP, as those given in Appendix A of [MUA-STS] (whose one of the authors was also one of the authors of [RFC4642]), implicit TLS is the preferred way of using TLS with NNTP. It is the only paragraph where I still mention "strict TLS configuration" because I reference RFC 7525. In all other parts of the draft, only "implicit TLS" terminology is now used. Thanks for your suggestion! -- Julien ÉLIE « J'ai le pied gauche qui est jaloux du pied droit. Quand j'avance le pied droit, le pied gauche, qui ne veut pas rester en arrière… passe devant… le pied droit en fait autant… et moi… comme un imbécile… je marche. » (Raymond Devos) _______________________________________________ Uta mailing list Uta@xxxxxxxx https://www.ietf.org/mailman/listinfo/uta