CAA and ACME for onions

Q Misell, Glauca Digital

CA/BF Validation Subcommittee
Thursday 7th of September 2023

Fedi: @q@glauca.space
Email: q@as207960.net

Overview

  • Introduce draft-ietf-acme-onion
  • Discuss reasoning for defining CAA for Tor
  • Technical implementation
  • Challenges and possible solutions

What is this standard for?

  • Allow automated issuance of certificates to Tor hidden services
  • Make .onion domains act as much like the DNS from a WebPKI perspective

Why even have certificates?

  • HTTP/2
  • PCI DSS
  • Security-in-depth
  • HTTPS only browser features
    • Secure cookies
    • Content Security Policy

Validation methods in draft-ietf-acme-onion

  • BR § 3.2.2.4.19 - Agreed-Upon Change to Website - ACME
  • BR § 3.2.2.4.20 - TLS Using ALPN
  • BR § B.2.b - Special CSR (onion-csr-01)

Current state of the standard

  • Adopted as an IETF working group document
  • Reference CA implementation
    acmeforonions.org
  • Certbot plugin for onion-csr-01
    certbot-onion
  • Tor Spec Proposal 343-rend-caa

Why CAA?

  • Consistency with every other TLD
  • Reduce chances of mis-issuance
  • Enforce organisational policy
  • Publish IODEF endpoint/contact details

How?

Extra field in the Tor hidden service descriptor

Overview of the Tor hidden service descriptor

Outer layer

Fetched with the service's blinded public key


hs-descriptor 3
descriptor-lifetime ...
descriptor-signing-key-cert
-----BEGIN ED25519 CERT-----
...
-----END ED25519 CERT-----
revision-counter ...
superencrypted
-----BEGIN MESSAGE-----
...
-----END MESSAGE-----

First layer encrypted data

Encrypted with the service's (non-blinded) public key


desc-auth-type x25519
desc-auth-ephemeral-key ...
auth-client ...
auth-client ...
auth-client ...
encrypted
-----BEGIN MESSAGE----
...
-----END MESSAGE-----

Second layer encrypted data

Encrypted with data from auth-client


create2-formats 2
introduction-point ...
onion-key ntor ...
auth-key
-----BEGIN ED25519 CERT-----
...
-----END ED25519 CERT-----
enc-key ntor ...
enc-key-cert
-----BEGIN ED25519 CERT-----
...
-----END ED25519 CERT-----
introduction-point ...

Client authentication

Tor allows hidden services to restrict which clients can connect using client authentication.

CAA records

.onion domains aren't in the DNS, so standard CAA records can't be used. Instead, CAA records are encoded in the BIND zone file format the second layer hidden service descriptor. 


create2-formats 2
single-onion-service
caa 128 issue "test.acmeforonions.org;validationmethods=onion-csr-01"
caa 0 iodef "mailto:security@example.com"
introduction-point AwAGsAk5n...

CAA interaction with client authentication

New field in the first layer hiiden service descriptor to signal that there are CAA records in the second layer descriptor. 


desc-auth-type x25519
caa-critical
auth-client ...

Implementation challenges

  • CA's (may) need to run a Tor client
  • Audits for the Tor client
  • Client memory safety

http-01 and tls-alpn-01

Full Tor client connection required, no way around this.

onion-csr-01

  • More room for clever solutions
  • CA only needs a copy of the HS descriptor, not a full connection to the HS

Fetching the descriptor without Tor

  • Many Tor directory authorities are reachable over a standard HTTP connection
  • The descriptor and network consensus to verify it can be fetched without Tor

Sending the descriptor over ACME

Client could send its descriptor over ACME to avoid the CA having to compute the network hash ring

Questions?

Q Misell, Glauca Digital

Slide deck available at magicalcodewit.ch/cabf-2023-09-07-slides/

Fedi: @q@glauca.space
Email: q@as207960.net