On May 30, 2012, at 8:43 PM, Matt McCutchen wrote:
My understanding
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html)
is that a TLSA RRset at a given endpoint (DNS name + transport + port)
is not a guarantee that a TLS service is offered at that endpoint. It
only indicates the server certificates to be considered authentic if a
client wants to attempt a connection to such a TLS service.
Correct.
Indeed, an
organization with an existing private CA may publish may cover its
entire zone with TLSA RRsets of usage 2 referring to that CA. And I
cover all the unused names in mattmccutchen.net with dummy TLSA RRsets
(SHA256 0000...0000) to ensure that TLS clients will never successfully
authenticate a TLS service that I do not offer if a MITM attacker tries
to spoof one into existence with a fraudulent certificate from a public
CA.
It could do so if it wanted. That doesn't mean it is a good idea to do so.
A mail client that is already configured to require authenticated TLS
could certainly use DANE. But it would be incorrect for a client to
refuse to deliver insecurely because it found a secure TLSA RRset.
That's incorrect. draft-fanf-dane-smtp is defining the specific use of TLSA for
_25._tcp.hostname. (It would be good if it said so in the Introduction.)
For
that kind of logic, we need something like HASTLS.
The second paragraph of the Security Considerations covers this. I think HASTLS
might be a good idea, but the IETF still needs to have the discussion of
layering of these types of announcements.
This approach is not going to work.
It will work fine for everyone who doesn't do the "cover every port and assume
that no future protocol will ever define how specific applications will use
TLSA".
--Paul Hoffman