In message <20150301202727.GD1260@xxxxxxxxxxxxxxxxxxxxx>, Viktor Dukhovni write s: > On Sun, Mar 01, 2015 at 10:21:33AM -0500, Phillip Hallam-Baker wrote: > > > On Sat, Feb 28, 2015 at 5:27 PM, Mark Andrews <marka@xxxxxxx> wrote: > > > > > > > > And that is coming "_25._tlsa" and it uses DNSSEC to prevent the > > > downgrade. > > Typo fix: that "_25._tlsa" is of course "_25._tcp". Thanks > > > Whether your MTA uses STARTTLS or not is another matter > > > but we can prevent downgrade attacks from succeeding. > > If the MTA implements opportunistic DANE TLS, and usable TLSA > records *are* published, then it MUST use STARTTLS and authenticate > the peer via said TLSA records. > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-2.2 I was refering to the fact that publishing records doesn't force the client to use TLS as we have a large legacy population. New client will do this if they are not broken. That said, adding explict compliance tests to the rfc may not be a bad idea but this thread is not the place to discuss it. I wish EDNS had explict compliance tests listed so we would not be in the mess we are in today. Again this thread is not the place to discuss this. > > In particular make it possible to explicitly specify criteria such as 'use > > TLS transport' or 'XYZ authentication is required'. > > For both MX and SRV the DANE WG has settled on publication of TLSA > RRs to signal both "TLS is required" and "DANE authentication is > required". Yep > -- > Viktor. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx