On Fri, Dec 23, 2016 at 09:24:03PM +0100, Julien ÉLIE wrote:
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.
Minor correction. The term "mandatory TLS" in RFC7672 is not
describing the same thing as "implicit TLS". Rather it describes
use cases in which TLS is required by policy, typically in the
context of STARTTLS (RFC 7672 is afterall an MTA-to-MTA TLS document).
With mandatory TLS, STATTLS stripping is not effective, because
the client will refuse to proceed in the absence of TLS support.
The same holds with opportunistic DANE TLS clients, when the server
publishes DANE TLSA records.
--
Viktor.