<div dir="ltr"><div class="gmail_extra"><br class=""><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 9:28 PM, Paul Syverson <span dir="ltr"><<a href="mailto:paul.syverson@nrl.navy.mil" target="_blank">paul.syverson@nrl.navy.mil</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">First, Tor is transitioning to SHA-256 and ed25519.  This has already<br>been incorporated in alpha releases over the last c. half year. And<br>there are many existing sites with DV certs still supporting RSA<br>1024. So this is a temporary issue and one that would hardly be unique<br>to onionsites.<br></blockquote><div><br></div><div>But it is. Domain names have a single, canonical source of registration. Someone is either the domain registrant at the time of validation, or they are not - and that information and audit trail can be maintained.</div><div><br></div><div>However, .onion domains are necessarily different, in that there can be multiple registrants - any party who can exploit cryptographic weaknesses of the .onion naming can legitimately masquerade as the domain holder.</div><div><br></div><div>In the current .onion deployment, the mitigations against this relate to strongly binding the issuance to identity (arguably, and understandably so, too strongly - but better to be too strong than too weak), and in requiring that the full cryptographic identifier be embedded in the certificate (rather than just relying upon the .onion cryptographic naming scheme)</div><div><br></div><div>This latter part may not seem like a defense in and of itself; for example, when .onion is operating transparently at a layer underneath the application (e.g. in most practical deployments), the user agent validating the certificate is not responsible for establishing the .onion connection (that's often handled via either proxy or through network rules on a secondary device, the latter being more secure for anonymity purposes), and thus cannot strongly bind the .onion to the certificate validation.</div><div><br></div><div>However, the 'mitigation' arises from the not-unintentional side-effect that at present, one major browser requires such certificates to be disclosed via Certificate Transparency, and, as a result, has the practical effect of publicly sharing information related to the full .onion name, such that a cryptographic attack (such as a SHA-1 collision) can be detected after-the-fact.</div><div><br></div><div>Put differently:</div><div>Risk: .onion is at risk of SHA-1 collisions</div><div>Mitigation: The disclosure in certificate transparency reveals an attacker exploiting a SHA-1 collision (by virtue of the Tor Service Descriptor extension</div><div><br></div><div>Risk: .onion is at risk of RSA key factoring</div><div>Mitigation 1: The EV requirement requires attributing who the factoring party is</div><div>Mitigation 2: The disclosure in certificate transparency reveals an attacker exploiting RSA factoring (by virtue of the Tor Service Descriptor extension</div><div> </div><div>When you take away the "EV" requirement, you intrinsically take away these mitigations, which is why those proponents for DV (which, purely on a policy level, I have no objections to) need to consider how to mitigate such attacks.</div><div><br></div><div>Further, the introduction of DV into the .onion space introduces the opportunity for a 'downgrade attack', in which an attacker that wishes to attack an EV onion site (such as Facebook) 'simply' factors Facebook's 1024-bit key / mounts a SHA-1 attack, and then obtains a DV certificate for such a site. This means we're now regressing from a 'higher' layer of security to a 'lower' one.</div><div><br class="">Finally, ANY form of cryptographic attack on a .onion name forever destroys the utility in that name; a full cryptographic migration is necessary, which means a new name being created. This is unlike that of DNS, where even under a misissuance or attack scenario, the duration of the attack can be bounded by factors such as how long BGP routes were poisoned or how long the misissued certificates are valid, and steps can be taken. However, because the coupling on keys to identifier, a full mass exodus from the existing name is necessary - which may or may not be viable, depending on how the .onion name was used. Again, this is also a scenario where the introduction of DV advantages attackers in their ability to attack high value targets (... such as all the current users of EV .onion certs), and that sort of asymmetry is one that must be accounted for in any proposals to introduce such non-EV schemes.<br></div><div><br></div><div>These aren't insurmountable problems; I can certainly think of and make suggestions for how to overcome them. But rather than seed a particular line of thinking, I'd rather explain the "Why" and "How" this came to be, so that proponents can thoughtfully consider and, using their own domain expertise in the Tor protocol, software, and schemes, offer ways to be able to allay those concerns.</div><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">But more importantly, according to the currently published BR from<br><a href="http://cabforum.org/" rel="noreferrer" target="_blank">cabforum.org</a> (1.3.0), checks for DV Cert authorization validation<br>include "Having the Applicant demonstrate practical control over the<br>FQDN by making an agreed‐upon change to information found on an online<br>Web page identified by a uniform resource identifier containing the<br>FQDN".<br></blockquote><div><br></div><div>My message was not at all disputing that .onion names could be validated using the existing methods - or the upcoming ballots from the Validation WG.</div><div><br></div><div>Rather, it was pointing out the inherent security risk in doing so, because .onion names are 'different' than how DNS names are assigned, and that you have the (however unlikely) event of two parties arriving at the same name.</div><div><br></div><div>At a protocol level, you still have to get that HS announced out there, so there are arguably some detection mechanisms intrinsic to Tor, but frankly, I would rather avoid hitching my wagon to that.</div><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">Whatever cryptographic weaknesses these may have, they are still far<br>stronger than what an applicant for a registered domain accessed via<br>unencrypted HTTP would be demonstrating.  (The Sept 10 draft revisions<br>would not substantively change this observation.)<br></blockquote><div><br></div><div>I'm not sure I agree with this assessment.</div><div><br></div><div>On the obvious level, an attack mounted against such a domain necessarily requires a privileged position in the network between the CA and the site under attack. Such attacks 'generally' leave footprints if mounted remotely (e.g. via BGP poisoning), although admittedly don't if under a nation-state adversarial model where they can coerce or convince an employee at an on-hop ISP to interpose.</div><div><br></div><div>With .onion, the attack doesn't become detectable until the attacker poisons the HS announcements, since they can obtain the issuance of the certificate under provision 2(b) of Appendix F (signing a CSR w/ the onion service key). As a result, detectability of a population under attack doesn't happen *until* the attack happens, which is a weaker guarantee.</div><div><br></div><div>Equally, because .onion acts as a hostname resolver, it lacks the ability to employ supplemental records like CAA as a way for a .onion operator to reduce the attack scope to a set of CAs that they trust to employ suitable checks, including making prior arrangements such as who is the responsible party for approving issuance for that .onion name. Effectively, the first party to operate the .onion service - which inevitably will be the 'victim' site - can prevent the 'attacker' site from ever getting a cert, even under a cryptographic attack; this, combined with HSTS, and mitigate the inherent security risks of the present .onion naming scheme.</div><div><br></div><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">And the argument from policing domain content seems a complete red<br>herring.  Regardless of whether we agree with CA policing of<br>subscriber's content or not, a CA unhappy with the content of an<br>onionsite could revoke its certificate the same as they could for a<br>registered domain for which they issued a certificate.<br></blockquote><div><br></div><div>I didn't say it was an argument I agreed with, but alas, saying it's a "complete red herring" is likely to cause those who hold such deep beliefs to have knee-jerk reactions based not on logic or technical arguments, but because they feel their concerns are unaddressed. So it is a practical necessity, not a technical one, to at least meaningfully address the implications of introducing a scheme which is potentially fully anonymized and decentralized and 'might' be used to host illicit or undesirable content. CAs which bank on reputation, or which hold the belief that CA's role includes acting as police of the Internet, will necessarily be concerned about such a scheme, and so it deserves a bit more treatment than 'just revoke it'.</div><div><br></div><div>This is, again, practical advice that was a heavy part of the original discussions for .onion, so it should not be blithely or glibly dismissed.</div></div></div></div>