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
s
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.
--
HLS
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org