On 25 October 2012 23:40, Rick Andrews <[email protected]> wrote: >> -----Original Message----- >> From: Chris Palmer [mailto:[email protected]] >> Sent: Wednesday, October 24, 2012 5:57 PM >> To: Rick Andrews >> Cc: Ben Laurie; Phillip Hallam-Baker; [email protected]; Paul >> Hoffman >> Subject: Re: [therightkey] Impact on issue processes >> >> On Wed, Oct 24, 2012 at 10:09 AM, Rick Andrews >> <[email protected]> wrote: >> >> > It's not a question of being unable to modify our software. As a >> representative of Symantec, I will tell you that modifying our issuance >> code will be a very tough sell, for a number of reasons: >> > - There's no obvious direct return on investment >> > - For some types of certificates, speed of issuance is very >> important. Getting a CT proof will slow this down and cause it to fail >> if the log server isn't up 100% of the time. >> > - It makes sense to avoid relying on external parties to fulfill >> part of our cert issuance process. At this point, it's unclear who >> would even host a log service, what SLA they would provide, how much >> attention they would pay to performance and availability, disaster >> recovery, etc. >> > - Symantec would not be interested in hosting a log service because >> of unclear ROI. >> >> CT makes CAs less valuable targets. I'd call that ROI. > > Ben, Chris, > > Protecting users is certainly a motivation and making our customers and their > end users safer on the Internet is my main goal. I'm not opposed to CT > because I don't want to protect users or CAs. I'm just not convinced it's the > best solution. > > It's going to cost engineering time and money for CAs to implement CT. The > bean counters and execs who control the purse strings are going to ask what > they'll get for their $$$. They'll ask "so if I spend this money, we won't > get hacked, right?" and I would have to say no, it's no guarantee that we > wouldn't get hacked, but if we got hacked we would know about it. > > CT is *a* solution, but by no means the only possible solution. Is there > another solution that might be less expensive and intrusive to implement? CAA > might get us 80% of the way there for a fraction of the cost. DANE and cert > pinning also help, and might be simpler to implement.
I think the answer is that, no, there isn't another solution that is easier. Getting 80% of the way might as well be getting none of the way - unless _all_ CAs (or other issuers) are constrained, the problem is not solved. DANE and CAA, even if they were deployable, still leave you open to trusted third parties, and we've seen how that's gone. Pinning has its own issues - and in any case is available now and has not fixed the problem. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
