[cabfpub] Personal Certificates for ".onion"

[Ryan Sleevi]

On Mon, Nov 9, 2015 at 9:28 PM, Paul Syverson <paul.syverson at nrl.navy.mil>
 wrote:

> First, Tor is transitioning to SHA-256 and ed25519.  This has already
> been incorporated in alpha releases over the last c. half year. And
> there are many existing sites with DV certs still supporting RSA
> 1024. So this is a temporary issue and one that would hardly be unique
> to onionsites.
>

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.

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.

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)

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.

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.

Put differently:
Risk: .onion is at risk of SHA-1 collisions
Mitigation: The disclosure in certificate transparency reveals an attacker
exploiting a SHA-1 collision (by virtue of the Tor Service Descriptor
extension

Risk: .onion is at risk of RSA key factoring
Mitigation 1: The EV requirement requires attributing who the factoring
party is
Mitigation 2: The disclosure in certificate transparency reveals an
attacker exploiting RSA factoring (by virtue of the Tor Service Descriptor
extension

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.

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.

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.

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.

But more importantly, according to the currently published BR from
> cabforum.org (1.3.0), checks for DV Cert authorization validation
> include "Having the Applicant demonstrate practical control over the
> FQDN by making an agreed‐upon change to information found on an online
> Web page identified by a uniform resource identifier containing the
> FQDN".
>

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.

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.

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.


> Whatever cryptographic weaknesses these may have, they are still far
> stronger than what an applicant for a registered domain accessed via
> unencrypted HTTP would be demonstrating.  (The Sept 10 draft revisions
> would not substantively change this observation.)
>

I'm not sure I agree with this assessment.

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.

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.

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.


And the argument from policing domain content seems a complete red
> herring.  Regardless of whether we agree with CA policing of
> subscriber's content or not, a CA unhappy with the content of an
> onionsite could revoke its certificate the same as they could for a
> registered domain for which they issued a certificate.
>

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'.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151109/64ea284e/attachment.html