[tor-dev] Specification for 'How to Safely Sign a statement with a .onion key'

[Tom Ritter]

Attached is a document written in the specification format for one
aspect of CA-signed .onion addresses - specifically a "What is a safe
way to sign (or not sign) a statement using the .onion key"  It
presents a couple options - I'd love to get feedback from folks on
which they prefer.

I recognize that no consensus or decision has been reached on whether
to encourage or guide CAs on issuing .onions. (Although I'm in
favor[0].)  Although this is obviously written skewed towards CAs, it
addresses a generic problem, and could be rewritten in that form.

Excerpting from the Introduction/Motivation:

   Several organizations, such as Facebook, (collectively,
   'applicants') have expressed a desire for an end-entity
   SSL certificate valid for their .onion Hidden Service
   address signed by a Certificate Authority (CA) present in
   browser trust stores.

   The existing Facebook .onion URL was issued by Digicert under
   a loophole in certificate issuance requirements. The Basic
   Requirements [0] is a document created by the Certificate
   Authority/Browser Forum that governs acceptable certificate
   issuing policies. Adherence to its policies is required for
   inclusion in many browsers' trust stores. .onion counts as
   an 'internal hostname' as it is not a recognized TLD by IANA.
   November 1, 2015 sets the deadline for when all internal server
   certificates must be revoked and no new certificates may be
   issued. Resolving the requirements and preferences for issuing
   .onion certificates before this date is extremely desirable, as
   it will determine if organizations such as Facebook will invest
   in the time and engineering effort needed to deploy Hidden
   Services.

   The full requirements for issuing .onion certificates is TBD,
   although recognition of .onion by IANA as a reserved domain is
   likely required.

   During discussions about the requirements for issuing for
   .onion one question that has arisen is what is a safe way to
   assert ownership of a .onion address and format an x509
   certificate with a .onion Subject Alternate Name (SAN).
   This document is designed to address some of those questions.

-tom

[0] https://lists.torproject.org/pipermail/tor-dev/2014-November/007786.html
-------------- next part --------------
Filename: XXX-recommendations-for-onion-certifiates.txt
Title: Recommendations for CA-signed .onion Certificates
Authors: Tom Ritter
Created: 23 November 2014
Target: n/a
Status: Draft

1. Intro and motivation

   Several organizations, such as Facebook, (collectively, 
   'applicants') have expressed a desire for an end-entity 
   SSL certificate valid for their .onion Hidden Service 
   address signed by a Certificate Authority (CA) present in 
   browser trust stores.

   Applicants want a CA-signed .onion address for several reasons,
   including:
    - Architectural reasons, where the existing web server
      expects and requires SSL 
    - Removing the existing 'Invalid Certificate' warning when 
      accessing a .onion URL over https
    - Public attribution of ownership of the .onion address

   The existing Facebook .onion URL was issued by Digicert under
   a loophole in certificate issuance requirements. The Basic 
   Requirements [0] is a document created by the Certificate 
   Authority/Browser Forum that governs acceptable certificate 
   issuing policies. Adherence to its policies is required for 
   inclusion in many browsers' trust stores. .onion counts as
   an 'internal hostname' as it is not a recognized TLD by IANA.
   November 1, 2015 sets the deadline for when all internal server
   certificates must be revoked and no new certificates may be 
   issued. Resolving the requirements and preferences for issuing
   .onion certificates before this date is extremely desirable, as
   it will determine if organizations such as Facebook will invest
   in the time and engineering effort needed to deploy Hidden 
   Services.  

   The full requirements for issuing .onion certificates is TBD,
   although recognition of .onion by IANA as a reserved domain is
   likely required.

   During discussions about the requirements for issuing for 
   .onion one question that has arisen is what is a safe way to 
   assert ownership of a .onion address and format an x509 
   certificate with a .onion Subject Alternate Name (SAN).
   This document is designed to address some of those questions.

2. Ownership of a .onion

   A .onion address is an 80-bit truncation of the SHA-1 hash of 
   the Hidden Service's public identity key (which is RSA 1024).
   To assert that an entity has control of a .onion address, an 
   entity could do one of several things.

2.1 Well Known URI 

   RFC5785 [1] specifies a path prefix for "well known locations". 
   A CA could require an applicant to post a specific value at
   a well-known URI.  Because of the nature of .onion addresses,
   this ensures that successful completion of this challenge is
   limited to:

   i.   The legitimate owner of the .onion domain
   ii.  Someone who possessed their private RSA key
   iii. Someone who achieved a 2^80 collision of SHA-1(RSA_Pub)
        for another RSA_pub

   An advantage of this system is that the .onion private key 
   material is not used in any other situation than the normal 
   Hidden Services protocol(s).  

   A disadvantage of this system is that it requires the 
   application to deploy a HTTP server to apply for their 
   certificate.  While we can expect many if not most of the 
   applicants are seeking a certificate for a HTTP server,
   certificates could also be legitimately requested for 
   XMPP servers, mailservers, or other protocols. However, 
   it would not be extremely difficult for an applicant to 
   temporarily stand up an HTTP server.

2.2 Signing with the .onion key

   Because the .onion address is a (truncated hash of a) 
   representation of the key - the underlying key can be sign
   a request for a certificate.  

   A signature should contain a sufficiently random value
   chosen by the CA to assure them a fraudulent applicant 
   could not obtain a signed statement with it in it.

   A signature should also contain a sufficiently random
   value chosen by the application to assure them the CA
   is unable to completely choose the content of the signed 
   statement.

   A major concern with this approach is reusing the key 
   material for two purposes: signing a statement at the 
   request of the CA and participating in the Hidden 
   Services protocol(s). If one is not careful, one may 
   enable cross-protocol attacks. There are at least two 
   approaches to mitigating this concern.

2.2.1 Sign a close-but-invalid HS descriptor

   In this approach, the Hidden Service descriptor format,
   as specified in spec #114 [2], is carefully taken into 
   account. Specifically, the signed data is carefully chosen
   to almost-parse as a valid descriptor, but fail one or more
   specific checks.  This is made simpler by there being limited
   implementations and opportunities for cross-protocol 
   attacks.

   The descriptor-content format is:

   descriptor-content = {
      descriptor-id,
      version,
      public-key,
      h(time-period + cookie + replica),
      timestamp,
      protocol-versions,
      { introduction-points } encrypted with cookie
   } signed with private-key

   Checks that could fail include:
    - The descriptor-id could be invalid
    - The version number could != 2 and be reserved for no 
      future use
    - The publication time could be > 24 hours old and out 
      of date
    - The introduction points could contain invalid data, such 
      as invalid IP addresses or ports

   An advantage of this approach is that by following an 
   existing format but producing invalid data, future development
   is extremely unlikely to be affected.

   A disadvantage of this approach is it flirts with disaster. If
   a present or future implementation had a bug where an invalid 
   descriptor was accepted, this could enable an attack.  But, if
   for example an applicant signed an expired descriptor, a 
   vulnerable client would be vulnerable today and be vulnerable 
   through many more vectors than the CA signature request.

2.2.2 Sign a completely nonsensical string 

   In this approach, the applicant signs a long string chosen not
   to overlap with any existing formats.  For example, this string 
   may be a long ASCII statement: 

   "I, applicant, being of sound mind and body, do request...""

   An advantage of this approach is that is does not flirt with 
   disaster as in 2.2.1.  

   A disadvantage of this approach is that future development 
   would need to be carefully architected to not enable an attack.





[0] https://cabforum.org/about-the-baseline-requirements/
[1] https://tools.ietf.org/html/rfc5785
[2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/114-distributed-storage.txt#l288