<p dir="ltr">Fair enough.</p>
<p dir="ltr">I do, however, hope you take the time to review the past discussion, as it explains why Adrien's analysis and conclusions are not quite correct, and why the distinction of 1024-bit vs 2048-bit or, for that matter, of SHA-1 vs SHA-2, are nowhere near the critical hole they were presented as. I should also hope that the fact that it is I who am saying that - one of the most ardent opponents of weak crypto - should hopefully assuage some of those concerns.</p>
<p dir="ltr">Best</p>
<div class="gmail_quote">On Mar 1, 2015 9:33 AM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m still interested in Adrien’s answer.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Sunday, March 01, 2015 9:30 AM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p>Kirk, Adrian,<u></u><u></u></p>
<p>I encourage you to read the discussion of and leading to the ballot, which is available on the public list archives. The discussion somewhat quite exhaustively covered these issues, and more importantly, provide a rather detailed explanation why they are
 not as critical as Adrian suggests.<u></u><u></u></p>
<p>All the best,<br>
Ryan<u></u><u></u></p>
<div>
<p class="MsoNormal">On Mar 1, 2015 7:57 AM, "<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Very good analysis, Adrien – thanks.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Would you otherwise be satisfied with the recent Tor ballot if it required 2048 bit keypair/SHA-256 or higher? 
 Apparently Tor can only do 1024 bit/SHA-1 right now, but perhaps they can upgrade their security.  Do you have any other changes to suggest?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:14.0pt;font-family:"Bradley Hand ITC";color:#0f243e">Kirk R. Hall</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Operations Director, Trust Services</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Trend Micro</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><a href="tel:%2B1.503.753.3088" target="_blank">+1.503.753.3088</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:questions-bounces@cabforum.org" target="_blank">questions-bounces@cabforum.org</a> [mailto:<a href="mailto:questions-bounces@cabforum.org" target="_blank">questions-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Adrien Johnson<br>
<b>Sent:</b> Sunday, March 01, 2015 4:11 AM<br>
<b>To:</b> <a href="mailto:questions@cabforum.org" target="_blank">questions@cabforum.org</a><br>
<b>Subject:</b> [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Hello,<br>
I'm writing with serious concerns about the validation rules for .onion domains, which were voted on in
<a href="https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/" target="_blank">
Ballot 144</a> on February 18th 2015. The vote tally was 6 in favor, 2 against, and 13 abstaining, and the motion passed.<br>
<br>
There are some major security concerns which have been overlooked in this document which pose a risk to anyone relying on certificates issued along its procedures.<br>
<br>
These oversights are as follows:<br>
1) The definition of "owning" or "controlling" a .onion domain has not been sufficiently addressed<br>
2) There are no procedures for ensuring that the security of the SSL certificates issued by CAs for .onion domains is not undermined by weaker security in the underlying Tor system<br>
<br>
A .onion domain is unlike a normal global DNS name because it does not have a definite "owner". With normal global DNS names, the owner is clearly defined as the person or organization who holds the registration of the domain at an accredited domain registrar.
 CAs can determine in a number of ways of varying rigour that the person/organization they give a certificate to is the legitimate owner of the domain, or their agent. The fundamental contract of the CA is to deliver a certificate to their client which provides
 no greater assurance of the client's identity than the CA was able to verify. Verified domain control earns a domain validated certificate, business records earn an EV cert, etc. The idea of ownership is different for .onion domain names. By design there is
 no central repository of .onion domain names, they are meant to be independently verifiable. In fact, a .onion domain name is simply an encoded hash of the public key of a Tor hidden service (a Tor service reachable by a .onion domain name.) When a browser
 connects to a .onion domain, all it says to the Tor service is "connect me to the server presenting a certificate whose public key has this .onion domain as a hash." Anyone who has a keypair that hashes to a .onion domain can be called the "owner" of that
 domain, and if more than one person has such a keypair, there is more than one "owner" and there is nothing to distinguish them.<br>
<br>
By itself this idea of self-evident, cryptographically-provable domain ownership is not a problem, in fact it is more robust than a centrally controlled, centrally corruptible global registry, but it means the highest assurance SSL certificate a CA can responsibly
 issue has a fixed upper limit. The contract of the CA is to only certify a site owner's identity or a site visitor's security if the CA has independently verified that information. As I will show though, the maximum verification of identity and security that
 can be made of a Tor hidden service is currently alarmingly low, significantly lower than the CA/B Forum's guidelines for certificate issuance.<br>
<br>
What is a .onion domain name? <a href="https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames" target="_blank">
The Tor Project documentation</a> states:<u></u><u></u></p>
<p class="MsoNormal">If you decide to run a hidden service Tor generates an ​RSA-1024 keypair. The .onion name is computed as follows: first the ​SHA1 hash of the ​DER-encoded ​ASN.1 public key is calculated.
 Afterwards the first half of the hash is encoded to ​Base32 and the suffix ".onion" is added. Therefore .onion names can only contain the digits 2-7 and the letters a-z and are exactly 16 characters long.<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">This means two things: the .onion domain name is derived from the hidden service's keypair using an already deprecated hash function on public key, and then
<i>half the bits of the hash are discarded</i>. SHA-1 was deprecated by CAs in fear a SHA-1 collision could be used to create a rogue intermediate CA certificate, as was done in 2008 using an MD5 collision. It would be somewhat harder to attack SHA-1 here to
 impersonate an already existing .onion domain because it would require a preimage attack instead of an arbitrary collision, as in the rogue CA scenario. Needless to say though, discarding half the bits of the SHA1 hash makes an attack significantly easier.<br>
<br>
The second thing it means is hidden services all use 1024-bit RSA keys for communication and identity. Even if we ignore the weaknesses in the generation of .onion domain names and assume that a colliding keypair cannot be found, it's still only a 1024-bit
 RSA keypair, which is also deprecated. Given a 1024-bit public key, calculating the corresponding private key is currently within the reach of government and large corporate attackers, which is why the CA/B Forum has disallowed their issuance. 1024-bit RSA
 keys do not provide enough assurance that the holder of the private key is the same person or organization that was issued the legitimate certificate. If the 1024-bit RSA key of the hidden service is cracked or stolen, it cannot be revoked and reissued as
 an SSL certificate can. It must be abandoned and the service must move to a new .onion domain/keypair because controlling the 1024-bit RSA key itself is what defines "ownership" of the .onion domain.<br>
<br>
No certificate issued to a .onion domain can currently have greater than 1024-bit RSA security. Even if a 2048-bit or greater key is issued to a .onion domain, the 1024-bit key conferring ownership of the .onion domain is still the weak link. When the 1024-bit
 key is defeated, the attacker has just as much ownership of the .onion domain as the first user, and would be able to obtain an SSL certificate for it from any CA issuing .onion SSL certificates, and may even be able to request revocation of the first SSL
 certificate.<br>
<br>
Because the Tor system currently limits the certificate hash function used to generate .onion domains to the very weak half-SHA1, and because the maximum identity and security verification a CA can responsibly certify for a .onion domain is limited to 1024-bit
 RSA, less than the current CA/B guidelines for certificate issuance, no CA can responsibly issue SSL certificates for .onion domains at this time.<br>
<br>
In order for SSL certificates to be responsibly issued for .onion domains, several changes would need to be made. The hash function used to derive .onion domains from the hidden service's public key should be strengthened to a modern alternative such as SHA-256,
 and all the bits of the hash should be encoded in the .onion domain. Tor hidden services should transition to keypairs stronger than the current CA/B Forum guidelines for certificate issuance, and in the SSL certificate issuance process the CA should ensure
 that it does not provide a certificate with greater cryptographic strength than the underlying Tor hidden service certificate. This is because the upper limit of identity and security a CA can actually verify for a hidden service is limited by the strength
 of the underlying hidden service keys. Any greater strength in the SSL certificate than the hidden service certificate represents a stronger promise of the hidden service's identity and security than is actually possible, and so would violate the CA's contract
 to only certify true information.<br>
<br>
I deeply hope that the Tor service moves to stronger cryptography that meets the minimum requirements of the CA/B forum, and I hope modified procedures allowing SSL certificates to be issued to .onion sites are soon adopted, but unfortunately more work needs
 to be done before that can happen.<br>
<br>
Regards,<br>
Adrien Johnson<br>
<br>
<br>
<u></u><u></u></p>
</div>
</div>
<table border="0" cellpadding="0">
<tbody>
<tr>
<td style="background:white;padding:.75pt .75pt .75pt .75pt">
<table border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<pre><u></u> <u></u></pre>
<pre>TREND MICRO EMAIL NOTICE<u></u><u></u></pre>
<pre>The information contained in this email and any attachments is confidential <u></u><u></u></pre>
<pre>and may be subject to copyright or other intellectual property protection. <u></u><u></u></pre>
<pre>If you are not the intended recipient, you are not authorized to use or <u></u><u></u></pre>
<pre>disclose this information, and we request that you notify us by reply mail or<u></u><u></u></pre>
<pre>telephone and delete the original message from your mail system.<u></u><u></u></pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><u></u><u></u></p>
</div>
</div>
</div>


<table><tr><td bgcolor="#ffffff"><font color="#000000"><pre><table><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table></blockquote></div>