On Jul 10, 2014, at 6:07 PM, Claus Assmann <ietf-smtp(_at_)esmtp(_dot_)org>
wrote:
AFAIR some guys wanted to work on a draft for this. Considering the
most recent breach (some CA issued "bogus" certs for Google etc?):
is there any progress on this?
Dear Claus,
See http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane
PKI does not offer a practical means to audit certs provided by CAs. DANE can
constrain which CAs are able to offer certificates for a given domain, in
addition to offering a certificate without CAs.
In an effort to go ever faster...
https://isc.sans.edu/crls.html illustrates the level of data shared to handle
CRLs which are often ignored anyway. Most browsers attempt to cache stapled
certs for extended periods passed in the initial TLS exchange. CRLs are not
suitable for mobile devices nor are certs cached for weeks? This is somewhat
disconcerting considering the number of sites affected by the heartbleed
keep-alive scheme used in an effort to go faster as well.
To regain confidentiality and authenticity, potentially compromised servers
having a vulnerability must regenerate all key pairs and revoke and replace all
certificates linked to them. In general, all compromised authentication
meta-information must be replaced while being unable to confirm whether
affected systems themselves have become compromised.
The fix was released on April 7. 6 weeks later about 3 out of 4 of vulnerable
servers were patched, but their certs did not keep pace. At that point, about
1 out of 7 took steps needed to ensure the certs. Of course, vendors are quick
to offer "identity protection" which typically takes you to some website where
you enter more of your identity data for them to market it to other vendors
while not really caring whether your accounts are compromised or even tell you
one way or the other. We have yet to determine the cost of this mistake, but
it has shown a horrible lack of CA agility.
DNSSEC has its own built-in caching scheme and provides real transparency and
is less dependent on the routing infrastructure. Do we really need to offer
OCSP for StartTLS? It seems as though SMTP with DANE takes us where we want to
be. Is it time to stop seeing this as a nail needing a hammer?
Regards,
Douglas Otis
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp