<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 11:28 AM, Christian Heutger <span dir="ltr"><<a href="mailto:ch@psw.net" target="_blank">ch@psw.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="white" lang="DE">
<div class="gmail-m_8584637403765529083WordSection1"><span class="gmail-">
<p class="MsoNormal">> Indeed, if browsers aren't enforcing the rules, not following the rules can be a competitive advantage for CAs. That is, they can make more money by doing the wrong thing, even though its forbidden, and thus it's very hard to convince
them to do the right thing, the thing<u></u><u></u></p>
<p class="MsoNormal">> that they agreed to. By being able to enforce it in software, we help CAs resist the temptation to put the Internet at risk.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal">So the CAs can break the rules now for one year after another instead of many years in row? I can’t really follow that arguement.</p></div></div></blockquote><div><br></div><div>I think the misunderstanding is that I'm not saying it's OK for CAs to break the rules - it never is - but shorter validity times help reduce the time to enforce the rules. By enforcing the rules, any breaking of the rules<br>1) Is detected sooner<br>2) Doesn't have any advantage, because the software will reject it.</div><div><br></div><div>Under today's world, so long as you don't get caught and called out, CAs can find there are economic incentives to breaking the rules, as long as the software accepts it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_8584637403765529083WordSection1"><p class="MsoNormal"> If there are failures, revocation is required and reissue needed, if the validity period is 1, 3, 5 or 10
years. BR requirement failures are scanable, there are services out there doing that. CT already gives additional control. If you introduce new trusted validation rules, should be a one time thing and nothing done from year to year.</p></div></div></blockquote><div><br></div><div>Unfortunately, we all need to learn from our mistakes, and as CAs make mistakes with the validation rules, we need to adjust them to make sure we've taken steps to prevent them. That is, there's a class of mistakes that result from CAs intentionally violating the rules, but there's also a class of mistakes that result from CAs misunderstanding the rules. The second time can happen when things are unclear, or when the CA is not acting in the interest of the ecosystem, and thus "looking for loopholes" (much like you might find someone who is looking to reduce their taxes to take advantage of every possible loophole, since that's the most personally advantageous, even if it's not societally advantages)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_8584637403765529083WordSection1"><div><span class="gmail-">
</span><p class="MsoNormal">If I’m customer of a CA revoking certificates without notification and replacement deadline, I no longer will order any more certs from this CA.</p></div></div></div></blockquote><div><br></div><div>Ah, I see. Unfortunately, this argument - that it's the CA's responsibility to revoke - only works if revocation works. But even then - in a world where revocation works - we still have many of the issues I've raised.</div><div><br></div><div>The messages in <a href="https://cabforum.org/pipermail/public/2017-February/009471.html">https://cabforum.org/pipermail/public/2017-February/009471.html</a> and <a href="https://cabforum.org/pipermail/public/2017-February/009475.html">https://cabforum.org/pipermail/public/2017-February/009475.html</a> expand upon that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_8584637403765529083WordSection1"><div>
<p class="MsoNormal">... you say yourself here „relative tot he user’s perceived risk“, so I don’t see the need to revoke all and immediate. Revoke the real mis-issues, for other urgent situations give deadlines, so there are real not ignorable warnings for
the ones without reaction or really harming security, all others should be done better in future.</p></div></div></div></blockquote><div><br></div><div>I think the misunderstanding for many of the points raised in the part that I snipped is that we don't have a way to determine what was "really" misissued and what was simply done with a less secure method. Well, we don't have any way short of relying on the CA. And the problem is this threat model is that, when a misissuance happens, we don't really trust the CA.</div><div><br></div><div>I think a good example of this - where the CA didn't understand or downplayed the scope of the issue - might be found with an event that happened two years ago. You can read Google's initial remarks <a href="https://security.googleblog.com/2015/09/improved-digital-certificate-security.html">https://security.googleblog.com/2015/09/improved-digital-certificate-security.html</a> , but the more important part is with the follow-up, in <a href="https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html">https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html</a></div><div><br></div><div>And while that might seem like a one-off, it currently seems like we're already seeing a repeat of the issues with the same CA, as you can see in the following three messages:</div><div>- <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ</a><br></div><div>- <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ</a></div><div>- <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ</a></div><div><br></div><div>As you can see, when something 'bad' happens, relying on the CA to responsibly detect and disclose the issues is a challenge, especially when all the incentives of the ecosystem mean that there are benefits to be had if the CA hides or misrepresents misissued certificates, since then they can avoid revoking those certificates without warning or timeline, which then, as you note, will cause customers to change CAs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_8584637403765529083WordSection1"><div><p class="MsoNormal">As responded to Gervase before, I don’t talk about the certificate updates, I talk about rolling out new algorithms or other major changes, which require infrastructural changes to the environment, which can’t be done in one year.</p></div></div></div></blockquote><div><br></div><div>Sure. But to be clear and repeat: This ballot is only about making certificate updates more frequent, so that regardless of the change - new algorithms that take a long time to phase in, or smaller security improvements that can be done in months - consistently take effect within 13 months of their actual effective date.</div><div><br></div><div>I'm not saying we're going to change everything every year. Just that a year is the longest reasonable time to go without 'patching' a bug or being able to make sure it's fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_8584637403765529083WordSection1"><div><span class="gmail-">
</span><p class="MsoNormal">No, it doesn’t as automatism is only a side-effect discussed with this Ballot. The primary focus are the 13 months to phase out anything faster and moving forward faster and I see other methods for urgent issues the right solution instead
of limiting the lifetime and also not to just 13 months, for evolution I believe 39 months are a good timeframe, followable by enterprises, as a compromise I would also vote (however, I can’t vote) for 27 months, but less is unrealistic.</p></div></div></div></blockquote><div><br></div><div>You've misunderstood the point of this ballot then. It doesn't mean everything will be phased out in a year or less. It simply means that browsers can begin enforcing those changes - whatever they are - within a year of them being required. In the time between "when it's required" and "when it's enforced", the only protection you have is assuming that no CA, anywhere, that's trusted, will make a mistake. And that's a big risk - too big for the ecosystem - since mistakes happen, especially the more CAs you have, and doubly so when there are economic incentives to intentionally "make mistakes" if you can make money from it. </div></div><br></div></div>