Fwd: Wording for strict vs implicit TLS in <draft-elie-nntp-tls-recommendations-01.txt>

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