<div dir="ltr"><div>Reposting this on Brian's request.</div><div><br></div><div>---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Brian Smith</b> <span dir="ltr"><<a href="mailto:brian@briansmith.org">brian@briansmith.org</a>></span><br>Date: Tue, Apr 26, 2016 at 12:47 PM<br>Subject: Re: [cabfpub] Proposed new ballot on IP Addresses in SANs<br>To: Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>><br><br><br><div dir="ltr">[Please forward this to the mailing list.]<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com">sleevi@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The best solution would be for clients to be updated to follow RFC 2818 and check iPAddress entries in the SAN.<br></blockquote><div><br></div><div>Indeed, and Microsoft can solve this very easily, without the same risks and compatibility issues of nameConstraints.</div></div></div></div></blockquote><div><br></div></span><div>I agree. I'm also not trying to shame Microsoft. At the same time, it's clearly Microsoft's fault that Microsoft's software doesn't do the right thing. I don't see how the risks in Microsoft updating its software to become correct could be higher than the risks in other vendors updating their software to become incorrect.</div><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">To me, it seems that allowing string-ified IP address in dNSName entries in the SAN when the same IP address is included as an iPAddress entry in the SAN is a reasonable tradeoff.  It is no worse than including the same in the common name.</blockquote></div></div></div></blockquote><div><br></div></span><div>This is not true. In particular, not only would the subjectAltName parsing need to be changed, but name constraint processing would also need to be changed. For example, consider a constraint that disallowed all IP addresses. The code for enforcing that would be correct if it only looked at iPAddress subjectAltName entries (and the subject CN, if the implementation supports that deprecated practice). However, if one needs to emulate Microsoft's behavior then it would need to be changed to also look in dNSName entries for IP addresses. Depending on how the code is structured, that may be a very significant change.</div><div><br></div><div>Further, if the implementation doesn't support the deprecated practice of IP addresses in the subject CN, then it would need to add additional code to parse IP addresses into a format suitable for applying the iPAddress constraint. Note that an implementation has an IP Address parser for parsing URLs, but it might not be able to reasonably use that same parser in its certificate validation code.</div><div><br></div><div>Any/all of these kinds of changes add significant risks of adding bugs--not only bugs in processing IP addresses, but also bugs in processing other kinds of names, in particular DNS names. Such bugs could be disastrous for security.</div><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If you have a client that properly conforms to RFC 2818, then this is a no-op for you — you will look at the IPaddress entry and never try to match on DNSname.  You had expressed concern that Mozilla would need to update its code, but Gerv had indicated back in August that this was not necessary (<a href="https://cabforum.org/pipermail/public/2015-August/005850.html" rel="noreferrer">https://cabforum.org/pipermail/public/2015-August/005850.html</a>).<br></blockquote><div></div></div></div></div></blockquote><div><br></div></span><div>I am the person that wrote Mozilla's code in question. Mozilla failed to mention situations where it would in fact be problematic--In particular, the cases where name constraints are being used. </div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">That's not what is in the ballot. What is in the ballot can and will cause compatibility issues. It also suggests that Chrome would need to adopt Firefox's peculiar behaviour (only validating presented identifiers as they're encountered, rather than at parse time). That's not something we are comfortable with implementing</div></div></div></blockquote><div><br></div></span><div>Although I think "peculiar" is an unnecessarily negative characterization of Mozilla's implementation--which I personally think is brilliant--I do agree that it isn't reasonable to expect all other implementations to parse certificates in the "lazy" manner in which Firefox does.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">and especially not foisting upon the ecosystem to know about the "special" rules the CA/B Forum embraces. There's already enough magic in the WebPKI - we shouldn't knowingly introduce more.</div></div></div></blockquote><div><br></div></span><div>I agree.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">There's clearly a demonstration of CA value - they do less work - and of browser value - Microsoft does less work - but there has yet to be an articulation of why the solution is non-viable.</blockquote></div></div></div></blockquote><div><br></div></span><div>Not only that, but there also hasn't been any demonstration that this problem has *significant* impact (i.e. millions of users are affected).</div><div><br></div><div>For a very long time, Firefox did a terrible job at building certificate chains, causing real problems for many CAs and may websites. Mozilla recognized it had a technical problem, fixed it, and offered the solution to all of its users--for free. That was a significant investment of resources that involved rewriting the entire certificate validation subsystem. Mozilla could have, instead, proposed new CAB Forum rules to restrict CAs to doing what would work for its implementation--i.e. shift its costs to the community. But Mozilla didn't; instead Mozilla fixed their code.<br></div><div><br></div><div>Let's solve technical problems with code, and let's solve political problems with politics. This is a technical problem.</div><div><br></div><div>Cheers,<br></div><div>Brian</div></div><span class="gmail-HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><a href="https://briansmith.org/">https://briansmith.org/</a></div><div><br></div></div></div></div></font></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 2:44 PM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Apr 22, 2016 at 12:45 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So it would seem that this solution might not be the best option.<br></blockquote><div><br></div></span><div>"Not the best" isn't the goal. It's "Don't violate RFC5280" that should be the goal.</div><div><br></div><div>Multiple SANs is a complete red-herring as to the issue. There's no requirement that such certificates have them.</div><div><br></div><div>Common name deprecation is equally a red-herring. If it offers a viable path for these clients, without the attendant security issues and *fundamental violation of RFC5280*, it's worth exploring.</div><div><br></div><div>That there's been no further explanation other than "Meh" is, unquestionably, not a position we can endorse, but even moreso, a policy of "Oh well, we'll violate them anyways" is just grossly irresponsible.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The best solution would be for clients to be updated to follow RFC 2818 and check iPAddress entries in the SAN.<br></blockquote><div><br></div></span><div>Indeed, and Microsoft can solve this very easily, without the same risks and compatibility issues of nameConstraints.</div><div><br></div><div>We considered the RFC5280 non-criticality of nameConstraints because it offered significant positive security value for a majority of clients, without compatibility risks. The iPAddresses provide no positive security value - other than allowing CAs to sell to users with buggy software that their vendor doesn't want to fix - and come with significant compatibility and security risks.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To me, it seems that allowing string-ified IP address in dNSName entries in the SAN when the same IP address is included as an iPAddress entry in the SAN is a reasonable tradeoff.  It is no worse than including the same in the common name.  As you have pointed out, a string-ified IP address can never match a hostname, so there is no chance of confusion </blockquote><div><br></div></span><div>I've already explained to you why this is incorrect. It's unfortunate that you continue to suggest this line of thinking. A string-ified IP address is not a valid hostname.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If you have a client that properly conforms to RFC 2818, then this is a no-op for you — you will look at the IPaddress entry and never try to match on DNSname.  You had expressed concern that Mozilla would need to update its code, but Gerv had indicated back in August that this was not necessary (<a href="https://cabforum.org/pipermail/public/2015-August/005850.html" rel="noreferrer" target="_blank">https://cabforum.org/pipermail/public/2015-August/005850.html</a>).<br></blockquote><div> </div></span><div>That's not what is in the ballot. What is in the ballot can and will cause compatibility issues. It also suggests that Chrome would need to adopt Firefox's peculiar behaviour (only validating presented identifiers as they're encountered, rather than at parse time). That's not something we are comfortable with implementing, and especially not foisting upon the ecosystem to know about the "special" rules the CA/B Forum embraces. There's already enough magic in the WebPKI - we shouldn't knowingly introduce more.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I appreciate that conformance is a great goal, but not causing customer pain is also a laudable goal.  In this case it seems the risk is low and the customer value is high.<br></blockquote><div><br></div></span><div>There has yet to be a demonstration of the customer value compared to the solution posed 8 months ago.  There's clearly a demonstration of CA value - they do less work - and of browser value - Microsoft does less work - but there has yet to be an articulation of why the solution is non-viable. The closest comment is Jeremy saying they've investigated, it's not practical - but provided zero evidence or technical detail that would allow a reasoned weighing of the risk versus reward. Instead, we see CAs eager to violate RFC5280, easy to cause compatibility issues with clients, and w/o apparent care for the long-term damage to the ecosystem they would be doing.</div></div></div></div>
</blockquote></div><br></div>