Re: [dane] draft-fanf-dane-smtp

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

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