In message
<20150301202727(_dot_)GD1260(_at_)mournblade(_dot_)imrryr(_dot_)org>, 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(_at_)isc(_dot_)org>
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(_at_)isc(_dot_)org