> On Dec 19, 2016, at 4:11 PM, Julien ÉLIE <[email protected]> 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.
> 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"?
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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
