ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] certificate pinning

2014-07-10 22:30:15

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
<Prev in Thread] Current Thread [Next in Thread>