[cabfpub] Proposal of a SHA-1 exception procedure

[Dean Coclin]

On Thu, Jun 16, 2016 at 2:44 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

My suggestion was that the browsers be notified of those details but that they be redacted from the public document.

 

Right, in case it wasn't clear:

 

There is no desire from Google for any of this to happen in private. If at any part the answer is "Trust Google to have done due dilligence", that's simply a non-starter. That is not keeping the ecosystem risks in consideration, and is favoring a system that invites itself to compromise, coercion, or negligence.

 

I know that at least one Browser feels that openness is inconsistent with their principles. I can respect that, but I think we'd disagree. The issuance or non-issuance affects far more than just browsers or just financial services, and no special preferential treatment should be given to either those affected or those here in the Forum. If we are going to introduce security risks that threaten the entire ecosystem - from mobile devices, to IoT, to cars, to thermostats, to browsers, to server-side processing systems, and everything big or small that uses TLS with publicly trusted certificates, rightly or wrongly, then we need transparency.

 

>>There’s transparency and then there’s security. We need to find the right balance. And that’s what I thought we did with the suggested cryptanalysis. Anyone can do it, everyone can see the results. Seems transparent to me.  BTW-I didn’t say trust one browser. The intent was to provide info to all browsers. Unless all browsers are in collusion, this seemed like a fair request. 

As Jody stated in Bilbao, there is no point in exposing this information if it introduces security risks. He also said that we should be collectively trying to find a solution which involves compromise. To that end, I think Andrew has done a great job with his initial proposal, garnered from the discussion in Bilbao. But some fine tuning should be expected and hopefully we can find an amenable solution to all parties.


Today I participated on a call with FS-ISAC members in which they expressed a security concern about the current procedure. Hence my comments.

 

Care to elaborate what those concerns are, in the benefit of transparency and avoiding fear and uncertainty?

 

 

>>Exactly what I stated earlier. Giving out names puts a target on ones back and potentially releases security info. 

 

I’m wondering if a separate working group type call could be held to mash out a final, recommended document and present to the forum members. I’m not suggesting a formal working group, rather a subset of the normal meeting call in group that can work together to propose a final document.

 

Ultimately, I think it's up to each and every rootstore to separately evaluate what they see as appropriate risk to allow issuance, much in the same way they determine the appropriate risk to handle if a CA fails to follow those procedures.

 

Google's proposed a solution that embraces transparency, which we feel as a critical necessity for decisions that effectively put the entire TLS ecosystem at risk. It is unfortunate that others disagree. I think we're more than happy to entertain concrete concerns with the proposal, and absolutely amenable to change, but feel it's similarly necessary to have transparency over those discussions and concerns. As an organization frequently under the spotlight for matters of security, good and bad, I'm sure you can understand how important it is that there isn't an appearance of slinking off to smokey back rooms to hash it out in secret cabals. 

 

>>So far, everyone has been pretty open in our discussion and comments to the draft; following our forum rules.  I hope we can continue this way. However, it would be good to come to conclusion soon given impending expirations of critical infrastructure certificates and impact to the financial ecosystem. Having said that, I know for a fact that some CAs are working hard with the affected vendors to try every possible alternative before resorting to the procedure discussed here.  Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/31dcd6a9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/31dcd6a9/attachment-0001.p7s>