[tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification

[Shelikhoo]

Hi Q!

I have an alternative design of public key infrastructure for onion 
services that I would like you to consider. I have described it on 
https://gitlab.torproject.org/tpo/core/torspec/-/issues/171, and here is 
a rephrase of it.

In order to prove the ownership of an onion address and create a 
certificate, the onion service operator generate public and private key 
as usual, and sign [certificate public key, certificate fields (like 
expiry date, Subject Common Name) and extensions (like key usage)] with 
their onion service private key, and place the signature and a copy of 
signed data as non-critical extension of a CSR known as onion 
certificate seed.

This onion certificate seed can be either self-signed or submitted to 
certificate authority to become a full certificate. It can be submitted 
to certificate authority over ACME for certificate issuance. The onion 
key signature and signed data is copied to the final certificate as 
non-critical extension after validation.

For Onion Native Application (like Tor Browser), a TLS certificate is 
trusted if it is issued by a trusted CA, or it has a valid onion 
certificate seed extension. This means this certificate issue model does 
not absolutely need any cooperative CA to work, so long as Tor Browser 
and other Tor Native application supported it by default, it would work 
as expected. For some application designed specifically for Tor, a onion 
service without a valid onion certificate seed extension may be 
rejected. For non-Onion-Native applications, a certificate issued by 
certificate authority will be necessary for it to pass validation.

It has the following advantages compare to the plan mentioned in your 
email:
1. Since the certificate public key and expiry date is covered by onion 
key's signature, Certification Authority Authorization record is not 
necessary, as attacker could not generate a certificate under the 
attacker's control, since attacker have no access to the public key. 
This also allow certificate authority to issue certificate without the 
need to have access to the Tor network or the onion service. (CA don't 
wish to change the design of their airtight certificate issuing 
environment, don't force them)
2. For Onion Native Application, this design works on day 1 without the 
need of any cooperative CA. Since currently a lot of onion service is 
access with Tor Browser, it will allow Tor Browser to push the adaption 
of this design with its weight. CA hates to break thing, this design 
gets things rolling to force trusted CAs to adapt it.
3. For Onion Native Application, this design allows valid certificate to 
be generated without contacting third party and publishing the onion 
service address. This would allow sensitive onion service to use TLS 
encryption without revealing its address to third party or public.
4. The onion certificate seed can be generated offline, which allow it 
to be stored in a secure/offline location.
5. It does not require any change to the C-Tor/Arti implementation, 
since it does not require either CA or even the hidden service request 
certificate itself connected to the Tor network.

Shelikhoo

On 25/4/2023 1:02 pm, Q Misell via tor-dev wrote:
> Hi all,
>
> I've spent some time working on ACME for Tor hidden services (you may 
> have seen discussion of this work on the onion-advisors mailing list). 
> Full details of the project are available at https://acmeforonions.org 
> <https://e.as207960.net/w4bdyj/yBzJUPTT>.
>
> Attached is my proposal for a change to the Tor Rendezvous 
> Specification to support the inclusion of CAA records in hidden 
> service descriptors.
>
> My fork of Tor implementing publishing these records is available at 
> https://github.com/as207960/tor <https://e.as207960.net/w4bdyj/LmAkW3uG>.
>
> Thanks,
> Q
> ------------------------------------------------------------------------
>
> Any statements contained in this email are personal to the author and 
> are not necessarily the statements of the company unless specifically 
> stated. AS207960 Cyfyngedig, having a registered office at 13 
> Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca 
> Digital, is a company registered in Wales under № 12417574 
> <https://e.as207960.net/w4bdyj/pIFzAYXo>. ICO register №: ZA782876 
> <https://e.as207960.net/w4bdyj/pZ2mD5UQ>. UK VAT №: GB378323867. EU 
> VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 
> 522-80-03080. Glauca Digital and the Glauca logo are registered 
> trademarks in the UK, under № UK00003718474 and № UK00003718468, 
> respectively.
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230504/d6403667/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230504/d6403667/attachment.sig>