----- Original Message ----- From: "Viktor Dukhovni" <[email protected]> To: <[email protected]> Sent: Thursday, October 09, 2014 4:07 AM Subject: Re: [Uta] Opportunistic TLS and draft-ietf-uta-tls-bcp-04
> 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). Well, that is what you have in your I-D, that is what you are proposing. The question I raise is whether or not that definition of opportunistic TLS is the one that UTA wants to use Orit said "We have the "Opportunistic TLS" topic as one of the UTA potential deliverables, so we welcome the interested parties to write a separate draft on the subject ..... " Well, no. The charter does not mention opportunistic, so again, we lack a definition, or at least a link between whichever part of the charter people have in mind and the term "Opportunistic TLS". On the other hand, the charter does mention "Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. " which suggests to me that unauthenticated plain text - and your I-D does state that "When a TLS-encrypted communication channel is not available, message transmission takes place in the clear. " - is not our primary consideration i.e. the definition given of Opportunistic TLS in the I-D is not appropriate for UTA. Tom Petch > 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
