Subject: Re: [ietf-smtp] certificate pinning

From: Claus Assmann <[email-masked]>
Date: Thu, 10 Jul 2014 18:07:54 -0700

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?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jul 2014 20:29:54 -0700

> 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

---

From: Gilles Chehade <[email-masked]>
Date: Fri, 11 Jul 2014 11:02:59 +0200

> is there any progress on this?

I was willing to work on a draft but didn't get a reply and discusssion
drifted to dane and whatnot...

I'm still interested to contribute to the original idea.

-- 
Gilles Chehade

https://www.poolp.org                                          @poolpOrg

---

From: Brandon Long <[email-masked]>
Date: Tue, 15 Jul 2014 15:45:20 -0700

Summer vacations happened, and I'm still getting caught up.  I'll see if I
can get a draft together in the next week.

Brandon

On Fri, Jul 11, 2014 at 2:02 AM, Gilles Chehade <[email-masked]>
wrote:

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>