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(_at_)trigofacile(_dot_)com>
Organisation : TrigoFACILE -- http://www.trigofacile.com/
Pour : uta(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/uta