Subject: [Uta] draft-ietf-uta-email-deep-05: wording about strict vs implicit TLS

From: Julien ÉLIE <[email-masked]>
Date: Mon, 19 Dec 2016 22:11:29 +0100

Hi all,

draft-ietf-uta-email-deep-05 defines "Implicit TLS" in Section 4:  'a 
mechanism where TLS is negotiated immediately at connection start on a 
separate port (referred to in this document as "Implicit TLS")'

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)'.

I don't think any published RFC speak of implicit TLS, and I believe 
there should be consistent naming of the same notion between RFCs.  So, 
wouldn't it be better to use in draft-ietf-uta-email-deep the wording 
"strict TLS" instead of "implicit TLS"?

FWIW, I also use the "strict TLS" terminology in 
draft-elie-nntp-tls-recommendations-01 that is currently in IETF Last Call:
   https://www.ietf.org/id/draft-elie-nntp-tls-recommendations-01.txt

I hope that's fine, but of course it is still time to change it if 
"implicit TLS" is in fact the right wording to use.

-- 
Julien ÉLIE

« Il y a des gens qui parlent jusqu'à ce qu'ils arrivent à trouver
   quelque chose à dire. » (Sacha Guitry)

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Dec 2016 16:56:44 -0500

> On Dec 19, 2016, at 4:11 PM, Julien ÉLIE <[email-masked]> wrote:
> 
> draft-ietf-uta-email-deep-05 defines "Implicit TLS" in Section 4:  'a mechanism 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.

> there should be consistent naming of the same notion between RFCs.
> So, wouldn't it be better to use in draft-ietf-uta-email-deep the
> wording "strict TLS" instead of "implicit TLS"?

So long as "implicit TLS" is given a clear definition, it should be
fine.  Otherwise, "strict TLS" should be clearly defined as the
alternative to "STARTTLS", but I think that such a definition would
be contrary to a natural (naive) interpretation of the phrase.

-- 
	Viktor.

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 22 Dec 2016 17:07:07 +0100

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

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)