On Wed, Oct 08, 2014 at 09:45:20AM +0100, t.p. wrote:
> Opportunistic TLS is defined in
> http://www.ietf.org/id/draft-ietf-dane-smtp-with-dane-12.txt
> but as a deprecated concept, to be replaced by the term
No opportunistic TLS is NOT a deprecated concept, rather it is an
approach that is improved with opportunistic DANE TLS.
We'll continue to have opportunistic TLS (cleartext baseline,
unauthenticated TLS when possible) in SMTP for quite some time.
It is indeed at present a BCP for SMTP, since so few domains
(I have a list of ~240) have DANE TLSA RRs for SMTP.
> 'opportunistic DANE TLS'
> which is regarded as a superior approach.
It subsumes opportunistic TLS as a special case when TLSA RRs
are not published, but this is by far the majority of peer systems.
> It is tricky trying to coordinate terminology across different WGs:-(
Yes, that's a natural result of parallel work. So it is important
to try to keep abreast of activity in other groups, and thus I am
reading not only DANE WG, but also TLS WG and UTA WG traffic.
So we have:
- Opportunistic Security (proposed umbrella term)
- Opportunistic TLS (opportunistic security with TLS as
the channel security protocol, and unauthenticated TLS as
the ceiling).
- Opportunistic DANE TLS (opportunistic security with TLS as
the channel security protocol, and DANE authenticated TLS
as the ceiling for peers that publish TLSA RRs, but otherwise
opportunistic TLS for the remaining peers).
And it should be noted that Opportunistic DANE TLS is NOT always
authenticated! Being opportunistic, it is authenticated only when
possible (when peers publish TLSA RRs), and not otherwise.
It is not true that opportunistic security is not yet in use, and
thus out of scope for BCP documents. It has been in use with SMTP
for ~15 years (RFC2487 and RFC3207). It is now a BCP, with Google
reporting 72% inbound and 59% outbound TLS by volume (growing
gradually after a sharp increase up over the last year).
https://www.google.com/transparencyreport/saferemail/
It is however an option for *this* BCP document to say that
opportunistic TLS is out of scope, and then explicitly
exclude MTA-to-MTA SMTP, Server-to-Server XMPP, ... which
are of necessity opportunistic.
More broadly, any application protocol in which clients find servers
via MX, SRV, NAPTR, ... or other DNS indirection, cannot be protected
with Web PKI authentication, especially if it relies on STARTTLS
or similar signalling.
It seems to me that many people equate TLS with HTTPS, and assume
that the requirements for HTTPS are universally applicable to all
applications. This is not the case.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
