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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
