<div dir="ltr">Eddy,<div><br></div><div>I'm not sure whether CAs either can really be effective here in mitigating this, at least in the scope of subdomains. I think this is especially true when considering Mozilla's policy to allow technically constrained sub-CAs to issue certificates that are not audited to the BRs.</div>
<div><br></div><div>If I were to obtain a technically constrained sub-CA for <a href="http://mydomain.com">mydomain.com</a>, in which the CA fully vetted that ownership for <a href="http://mydomain.com">mydomain.com</a>, then I would be able to issue certificates for <a href="http://anydomain.com.mydomain.com">anydomain.com.mydomain.com</a>. That is, a technically constrained sub-CA behaves like a multi-level wildcard certificate.</div>
<div><br></div><div>Likewise, given a wildcard certificate for *.<a href="http://mydomain.com">mydomain.com</a>, I could create any degree of spoofables for <a href="http://anydomaincom.mydomain.com">anydomaincom.mydomain.com</a>. I suspect (but I'm not intimately familiar with) the possibility of Punycoding some degree there. I know this has been a point that Brad Hill has raised in the past.</div>
<div><br></div><div>I think when it comes to anti-phishing, this is something that may be better handled by the UAs, at least with respect to subdomains. You can already see this in UAs that highlight things like the "effective TLD+1" in their address bar, scrolling in particular to that location (eg: see Chrome on mobile platforms). That's not to say it's a perfect solution, by far, but it's a much more scalable solution that recognizes where the strengths and weaknesses are - and I think having CAs try to validate subdomains on the eTLD+1 is realistically a weakness that won't be solved effectively.</div>
<div><br></div><div>I think we still need to have the BRs concerned about spoofables at the eTLD+1 level, and still need to be concerned about high-risk requests, but when it comes to subdomains, I don't lose much sleep on this matter, at least when it comes to certificate issuance.</div>
<div><br></div><div>Put differently, I do not think the lock icon can be reasonably be considered an anti-phishing mitigation. It merely is an indication of the connection/encryption to the domain in question.</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:39 PM, Eddy Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<br>
On 09/10/2013 08:13 PM, From Jeremy Rowley:
</div><blockquote type="cite">
<div>
<p class="MsoNormal"><span style="color:#1f497d">I know we’ve
performed similar (non-malicious) experiments with DV certs
to see how easy it would be to phish a banking domain. It’s
pretty easy. I think this is a good launching point to
discuss how we can improve the BRs in a manner that prevents
these types of phishing attacks.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
</div>
</blockquote>
<br><div class="im">
In this respect I have a hot topic I'm supposed to check with the
CAB Forum, this comes convenient....<br>
<br>
From time to time we get requests for certificates that contain
possible domains within the host name, for example:<br>
<br>
<i><a href="http://domain.com.dom.net" target="_blank">domain.com.dom.net</a></i><br>
<br>
Now we have made an effort to disallow this practice as much as
possible recently because it could be easily abused:<br>
<br>
<i><a href="http://paypal.com.dom.net" target="_blank">paypal.com.dom.net</a></i><br>
<br>
Or to make it more obvious:<br>
<br>
<i><a href="https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649JDbg" target="_blank">https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649JDbg</a></i><br>
<br>
As it happens, some CAs issue such potentially confusing
certificates and we ourselves get every while requests for them. In
particular also from companies that provide or want proxy services
and in order to mask the names as much as possible it looks
something like this (this is from a real request):<br>
<br>
*.<a href="http://sharepoint.com.some.com" target="_blank">sharepoint.com.some.com</a> *.<a href="http://microsoftonline.com.some.com" target="_blank">microsoftonline.com.some.com</a><br>
*.<a href="http://outlook.com.shamir.adallom.com" target="_blank">outlook.com.shamir.adallom.com</a> *.<a href="http://office365.com.some.com" target="_blank">office365.com.some.com</a><br>
<br>
Which again could easily confuse a relying party which might or
might not know about the MITM going on. <br>
<br>
I would like to know what the stance of the membership here is on
this topic, in particular software vendors. And if there is room to
clarify this via regulation by the BR. Otherwise there is probably
no point in punishing our clients when others or they can get it
easily elsewhere.<br>
<br>
<br>
<div>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, COO/CTO</td>
</tr>
<tr>
<td> </td>
<td><a href="http://www.startcom.org" target="_blank">StartCom Ltd.</a></td>
</tr>
<tr>
<td>XMPP: </td>
<td><a>startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org" target="_blank">Join the Revolution!</a></td>
</tr>
<tr>
<td>Twitter: </td>
<td><a href="http://twitter.com/eddy_nigg" target="_blank">Follow Me</a></td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
</div></div>
<br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>