<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 3:06 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p dir="LTR"><span lang="en-us"></span><span lang="en-us"><font face="Calibri">Reposting to the Public list, with permission</font></span><span lang="en-us"></span><span lang="en-us"><font face="Calibri"> by the author</font></span><span lang="en-us"></span><span lang="en-us"><font face="Calibri">.</font></span></p></div></blockquote><div><br></div><div>Thanks Rick. I realize we've set time on our next agenda to discuss this, so I'm sure we'll get to more substantial concerns on the next call.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span></p><span class="">
<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"></span><span lang="en-us"><font face="Calibri">CAB Browser Forum,</font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri"> </font></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri">This message is from the AT&T Services, Inc., Chief Security Office, Data Protection Team. </font></span><span lang="en-us"><font face="Calibri"> </font></span><span lang="en-us"></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-us"><font face="Calibri"> </font></span></p>
<p dir="LTR"><span lang="en-us"><b></b></span><span lang="en-us"><b><font face="Calibri">ISSUE</font></b></span><span lang="en-us"></span><span lang="en-us"></span></p>
</span><p dir="LTR"><span lang="en-us"><font face="Calibri">We are writing about the SHA-1 deprecation policy that all trusted Internet Certification Authorities must comply. Our specific concern is the December 31, 2015 deadline for obtaining SHA-1 server certificates. This timeframe does not allow flexibility for our applications running SHA-1 certificates now with migration plans for the SHA-256 upgrade in 2016.</font></span><span lang="en-us"><font face="Calibri"> </font></span></p></div></blockquote><div>With regards to providing flexibility, this timeline was first (formally/publicly) announced on November 12, 2013, with Microsoft's policy update. Despite there being discussions of deprecation well before then, if we take that time as the first signal for CAs to begin deprecating, that left two years for organizations to begin planning and executing their migration. We're now three months from that date, and, as was discussed extensively during the CA/B Forum discussions of Ballot 118, we're now hearing suggestions that the sunset period be extended.</div><div><br></div><div>There was extensive debate, from a variety of CAs and Browsers, as to the appropriate dates. It's not surprising that several of the replies made (to you or from the management list) effectively reflect the same positions held and espoused during the extensive discussions around Ballot 118, which took nearly a year after MSFT's announcement to be formally codified and agreed. Considering that we are now three months from the deadline, it does not appear that there is new information being presented here - these were concerns very much taken into consideration during the previous discussions.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="h5">
<p dir="LTR"><span lang="en-us"><font face="Calibri">We successfully migrated to 2048-bit encryption keys using this method during the last PKI industry standard change and were assured the same option would be available for the SHA-256 migration in 2016.</font></span></p></div></blockquote><div><br></div><div>I'm sorry to hear, but that advice was inconsistent with the Baseline Requirements as of Ballot 118. While I'm certain it was inconsistent with Microsoft's published policies, there exists the possibility that Symantec reached some agreement with Microsoft for such an extension. However, it did not do so with other vendors who indicated support for and expectations of the same adherence, so it's unlikely that such a statement could have been given at the time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5">
<p dir="LTR"><span lang="en-us"><font face="Calibri">2) AT&T freezes non-emergency changes from mid-November through mid-January for zero customer service disruptions during the holidays. Technically we have less than three months to migrate the remaining SHA-1 certificates which equates to thousands of certificates. Three months does not provide sufficient time to deploy Symantec’s solution.</font></span></p></div></div></div></blockquote><div>No, but two years (Nov 12, 2013) seems like it would, and based on the proposed extension, it seems like one year (Ballot 118 passed 16 October 2014) would also have been sufficient.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<p dir="LTR"><span lang="en-us"></span><span lang="en-us"><font face="Calibri">3) Some applications can’t upgrade to SHA-256 until early to mid-2016 when vendor supported software is available.</font></span><span lang="en-us"><font face="Calibri"> </font></span></p></div></div></blockquote><div>This was extensively discussed as a concern, especially following the awful experience browsers had with deprecating MD-5 support. The dates chosen factored these concerns in.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<p dir="LTR"><span lang="en-us"><font face="Calibri">In closing, we agree with the CA Browser Forum’s intent but do not agree with the execution of this high business impact policy change that will involve many software providers, hardware vendors and businesses.</font></span></p></div></div></blockquote><div>This is why we began discussing it with a timeline aimed at nearly 5 years later. Unfortunately, the Internet moves at a far faster pace, and continues to accelerate. We saw that many software providers, hardware vendors, and businesses were either incapable or unwilling to act regarding MD5, which lasted half a decade after attacks were *known* and *practical*, and we saw the same concerns - and from a number of CAs - regarding SHA-1 deprecation.</div><div><br></div><div>While understanding of your plight, I do find it somewhat difficult to be sympathetic, given the efforts made to conduct this transition in an orderly fashion, and the ongoing efforts to publicize and draw the attention of software providers, hardware vendors, and businesses to this issue. It is equally, if not moreso, unfortunate that, according to you, you were provided with misleading information by your CA as to how the timelines worked.</div><div><br></div><div>As it stands, the Chrome team is opposed to any ballots to relax or extend the sunset, as our experience with MD5 has taught us that CAs and vendors alike will take advantage of such time to introduce greater issues and pain upon users. If a CA decides to issue such certificates, we would expect a qualified finding on the audit report, and expect those certificates to be revoked. While Chrome itself will reject these certificates, we do not believe that in and of itself provides sufficient mitigation for ecosystem-wide issues, and thus remain opposed to any extensions.</div></div></div></div>