New Proposal - CAA Extensions for the Tor Rendezvous Specification
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://e.as207960.net/w4bdyj/AX8Ffqsd 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://e.as207960.net/w4bdyj/XMN03dmD 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://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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.
On Tue, Apr 25, 2023 at 01:02:28PM +0100, Q Misell via tor-dev wrote:
Security Considerations: The second layer descriptor is encrypted and MACed in a way that only a party with access to the secret key of the hidden service could manipulate what is published there. Therefore, Tor CAA records have at least the same security as those in the DNS secured by DNSSEC.
Did you mean "signed"? If it's just encrypted and MACed, then anyone who can decrypt and check the MAC can also alter the contents, of course.
Yes, signed is what I meant. I will update the document. ------------------------------ 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://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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. On Thu, 27 Apr 2023 at 13:54, Ian Goldberg <iang@uwaterloo.ca> wrote:
On Tue, Apr 25, 2023 at 01:02:28PM +0100, Q Misell via tor-dev wrote:
Security Considerations: The second layer descriptor is encrypted and MACed in a way that only a party with access to the secret key of the hidden service could manipulate what is published there. Therefore, Tor CAA records have at least the same security as those in the DNS secured by DNSSEC.
Did you mean "signed"? If it's just encrypted and MACed, then anyone who can decrypt and check the MAC can also alter the contents, of course. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://e.as207960.net/w4bdyj/Clnj1LKF
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi Q and others, I have opened an issue about this proposal at https://github.com/cabforum/servercert/issues/433 and let's see how it goes. In this version I added that the onion certificate seed can also include nonce from CA and ACME client, so that it would have the same proof online key possession propriety of the current version of baseline requirement. Shelikhoo On 5/5/2023 8:39 pm, Q via tor-dev wrote:
Hi Shelikhoo,
Your suggestion seems sound, and I’d like to see it progress further. However it is not in the CA/BF BR, so is unusable by CAs, and therefore out of scope of my project.
I suggest you take up your new method with the CA/BF for addition to their BR.
Thanks, Q
On 5 May 2023, at 15:56, Shelikhoo <shelikhoo@torproject.org> wrote:
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/AJF219Qf>.
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/NmgPwb3o>.
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/grZU71IO>. ICO register №: ZA782876 <https://e.as207960.net/w4bdyj/QuNjuAbX>. 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://www.google.com/url?q=https://lists.torproject.org/cgi-bin/mailman/li...
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 25 Apr (13:02:28), 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://e.as207960.net/w4bdyj/AX8Ffqsd
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://e.as207960.net/w4bdyj/XMN03dmD
Thanks for this! I've merged this as proposal 343! I like it, this seems very simple approach especially for the ACME support that would allow us to roll in within the existing CA infrastructure. As you noted previously not perfect but this is what the world has right now. I took a look at your C-tor patch and I would strongly encourage you to submit a MR to our Gitlab. https://gitlab.torproject.org/tpo/core/tor Thanks! David -- F2eZmnZGZgRyoAIt8TzU0Fx4AWEAnpLssqomMgfaPes=
participants (5)
-
David Goulet -
Ian Goldberg -
Q -
Q Misell
-
Shelikhoo