[Top] [All Lists]

Re: draft-fanf-dane-smtp

2012-05-30 19:33:40

In message <4FC694AA(_dot_)2030206(_at_)isdg(_dot_)net>, Hector Santos writes:
Mark Andrews wrote:

My question is:

If the client has to be modified to do this extra TLSA check, then why 
not just add login to do a CA 3rd party repository?   Or support OCSP 
(Online Certificate Status Protocol) RFC2560?

OCSP is for when the CA knows the CERT is compromised.
TLSA, mode X, is to detect mis-issued CERT by some CA.

Different threat models.

OCSP are sometimes unreachable even when you have the address and CERT.
TLSA records will almost always be available if you can retrieve the addres
as they live below the address in the DNS and are usually in the same zone.

Different failure models.

Yes, but its always been used for whatever the CA responds with and 
whatever the client decides to do as a negative response, but as the 
modus operandi has been, a positive response has "trust value."  I've 
seen it used in cases where a browser check provides a perfect SSL 
resolution, but with modern browsers having OCSP enabled now, it will 
provide a failure/security notification to the user.  In the case I 
recall, a big national chain store purchased a set of wildcard 
domains, then wanted to add more the same day, and there was a 
revocation issue that failure when OCSP was enabled.

So I guess that all falls under a "compromise" threat/failure window.

When change is proposed, then it has to have a payoff.  A client 
trusting a self-signed signature is going to be pre-defined or 
pre-arranged or known upfront.

TLSA, mode Y, allows you to trust the self signed CERT by providing
a verifiable secure chain of trust back to a DNS trust anchor rather
than a CA trust anchor.

Thanks for your comments.

At best, this proposal offers an easier protocol. But its not ready 
for prime time until the DNS servers better support unnamed types and 
across the OS platform board.

Actually I believe it is ready for prime time.

If the DNS servers don't support DNSSEC then the MX, A and AAAA
will come back as insecure unless the administrators of the zones
are insane.

If the DNS servers do support DNSSEC and the MX, A and AAAA answers
come back as secure, then a TLSA lookup should succeed as the TLSA
lookups will be from the same zones as the MX, A and AAAA lookups
or will be in a secure zone beneath the zone that returned these
answers.  All DNSSEC aware servers are required to support unknown
types.  By checking the MX, A and AAAA results you elimitate the
possibility of NOTIMP on the TLSA lookup.

If DNSSEC is being broken then all bets are off.

I think we would like a SMTP/TLS model where clients support/service 
the CA market, in the same way Browsers do for SSL/TLS certificates. 
  I can see an SMTP Server Extension that offers service keywords for 
the level of enforcement. This may answer one of the lingering 
questions the DANE-SMTP drafts states that the server has no way to 
know the client has looked up a TLSA record.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org

<Prev in Thread] Current Thread [Next in Thread>