This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository torspec.
The following commit(s) were added to refs/heads/main by this push: new a14e298 prop343: Initial import a14e298 is described below
commit a14e2981efc6bf6ee49213189ca77118ca8c5216 Author: David Goulet dgoulet@torproject.org AuthorDate: Mon May 8 15:14:58 2023 -0400
prop343: Initial import
CAA Extensions for the Tor Rendezvous Specification.
Signed-off-by: David Goulet dgoulet@torproject.org --- proposals/000-index.txt | 6 +- proposals/329-traffic-splitting.txt | 2 +- proposals/343-rend-caa.txt | 107 ++++++++++++++++++++++++++++++++++++ proposals/BY_INDEX.md | 3 +- proposals/README.md | 3 +- 5 files changed, 116 insertions(+), 5 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index a838b94..381e7d4 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -249,7 +249,7 @@ Proposals by number: 326 The "tor-relay" Well-Known Resource Identifier [OPEN] 327 A First Take at PoW Over Introduction Circuits [DRAFT] 328 Make Relays Report When They Are Overloaded [CLOSED] -329 Overcoming Tor's Bottlenecks with Traffic Splitting [DRAFT] +329 Overcoming Tor's Bottlenecks with Traffic Splitting [NEEDS-REVISION] 330 Modernizing authority contact entries [OPEN] 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT] 332 Ntor protocol with extra data, version 3 [FINISHED] @@ -263,6 +263,7 @@ Proposals by number: 340 Packed and fragmented relay messages [OPEN] 341 A better algorithm for out-of-sockets eviction [OPEN] 342 Decoupling hs_interval and SRV lifetime [DRAFT] +343 CAA Extensions for the Tor Rendezvous Specification [OPEN]
Proposals by status: @@ -271,7 +272,6 @@ Proposals by status: 294 TLS 1.3 Migration 316 FlashFlow: A Secure Speed Test for Tor (Parent Proposal) 327 A First Take at PoW Over Introduction Circuits - 329 Overcoming Tor's Bottlenecks with Traffic Splitting 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience 342 Decoupling hs_interval and SRV lifetime NEEDS-REVISION: @@ -283,6 +283,7 @@ Proposals by status: 279 A Name System API for Tor Onion Services 291 The move to two guard nodes 317 Improve security aspects of DNS name resolution + 329 Overcoming Tor's Bottlenecks with Traffic Splitting OPEN: 239 Consensus Hash Chaining 240 Early signing key revocation for directory authorities @@ -305,6 +306,7 @@ Proposals by status: 330 Modernizing authority contact entries 340 Packed and fragmented relay messages 341 A better algorithm for out-of-sockets eviction + 343 CAA Extensions for the Tor Rendezvous Specification ACCEPTED: 265 Load Balancing with Overhead Parameters [for 0.2.9.x] 282 Remove "Named" and "Unnamed" handling from consensus voting [for 0.3.3.x] diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt index 44f2e4e..f2fe2e0 100644 --- a/proposals/329-traffic-splitting.txt +++ b/proposals/329-traffic-splitting.txt @@ -2,7 +2,7 @@ Filename: 329-traffic-splitting.txt Title: Overcoming Tor's Bottlenecks with Traffic Splitting Author: David Goulet, Mike Perry Created: 2020-11-25 -Status: Needs Revision +Status: Needs-Revision
0. Status
diff --git a/proposals/343-rend-caa.txt b/proposals/343-rend-caa.txt new file mode 100644 index 0000000..f5d449f --- /dev/null +++ b/proposals/343-rend-caa.txt @@ -0,0 +1,107 @@ +Filename: 343-rend-caa.txt +Title: CAA Extensions for the Tor Rendezvous Specification +Author: Q Misell q@as207960.net +Created: 2023-04-25 +Status: Open + +Overview: + The document defines extensions to the Tor Rendezvous Specification Hidden + Service descriptor format to allow the attachment of DNS style CAA records to + Tor hidden services to allow the same security benefits as CAA provides in the + DNS. + +Motivation: + As part of the work on draft-misell-acme-onion [I-D.misell-acme-onion] at the + IETF it was felt necessary to define a method to incorporate CAA records + [RFC8659] into Tor hidden services. + + CAA records in the DNS provide an mechanism to indicate which Certificate + Authorities are permitted to issue certificates for a given domain name, and + restrict which validation methods are permitted for certificate validation. + + As Tor hidden service domains are not in the DNS another way to provide the + same security benefits as CAA does in the DNS needed to be devised. + + More information about this project in general can be found at + https://e.as207960.net/w4bdyj/Gm2AylEF + +Specification: + To enable maximal code re-use in CA codebases the same CAA record format is + used in Tor hidden services as in the DNS. To this end a new field is added to + the second layer hidden service descriptor [tor-rend-spec-v3] § 2.5.2.2. + with the following format: + + "caa" SP flags SP tag SP value NL + [Any number of times] + + The contents of "flag", "tag", and "value" are as per [RFC8659] § 4.1.1. + Multiple CAA records may be present, as is the case in the DNS. + + A hidden service's second layer descriptor using CAA may look + something like the following: + + create2-formats 2 + single-onion-service + caa 0 issue "example.com" + caa 0 iodef "mailto:security@example.com" + caa 128 validationmethods "onion-csr-01" + introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3KHCZ... + + As the CAA records are in the second layer descriptor and in the case of a + hidden service requiring client authentication it is impossible to read them + without the hidden service trusting a CA's public key, a method is required to + signal that there are CAA records present (but not reveal their contents, + which may disclose unwanted information about the hidden service operator to + third parties). This is to allow a CA to know that it must attempt to check + CAA records before issuance, and fail if it is unable to do so. + + To this end a new field is added to the first layer hidden service descriptor + [tor-rend-spec-v3] § 2.5.1.2. with the following format: + + "caa-critical" NL + [At most once] + +Security Considerations: + The second layer descriptor is signed 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. + + The "caa-critical" flag is visible to anyone with knowledge of the hidden + service's public key, however it reveals no information that could be used to + de-anonymize the hidden service operator. + + The CAA flags in the second layer descriptor may reveal information about the + hidden service operator if they choose to publish an "iodef", "contactemail", + or "contactphone" tag. These however are not required for primary goal of CAA, + that is to restrict which CAs may issue certificates for a given domain name. + + No more information is revealed by the "issue" nor "issuewild" tags than would + be revealed by someone making a connection to the hidden service and noting + which certificate is presented. + +Compatibility: + The hidden service spec [tor-rend-spec-v3] already requires that clients + ignore unknown lines when decoding hidden service descriptors, so this change + should not cause any compatibility issues. Additionally in testing no + compatibility issues where found with existing Tor implementations. + + A hidden service with CAA records published in its descriptor is available at + znkiu4wogurrktkqqid2efdg4nvztm7d2jydqenrzeclfgv3byevnbid.onion, to allow + further compatibility testing. + +References: + [I-D.misell-acme-onion] + Misell, Q., "Automated Certificate Management Environment (ACME) + Extensions for ".onion" Domain Names", Internet-Draft + draft-misell-acme-onion-02, April 2023, + https://datatracker.ietf.org/doc/html/draft-misell-acme-onion-02. + + [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, + "DNS Certification Authority Authorization (CAA) Resource + Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, + https://www.rfc-editor.org/info/rfc8659. + + [tor-rend-spec-v3] + The Tor Project, "Tor Rendezvous Specification - Version 3", + https://spec.torproject.org/rend-spec-v3. diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index d0b1214..b1e6c62 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -246,7 +246,7 @@ Below are a list of proposals sorted by their proposal number. See * [`326-tor-relay-well-known-uri-rfc8615.md`](/proposals/326-tor-relay-well-known-uri-rfc8615.md): The "tor-relay" Well-Known Resource Identifier [OPEN] * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits [DRAFT] * [`328-relay-overload-report.md`](/proposals/328-relay-overload-report.md): Make Relays Report When They Are Overloaded [CLOSED] -* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting [DRAFT] +* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting [NEEDS-REVISION] * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries [OPEN] * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT] * [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 [FINISHED] @@ -260,4 +260,5 @@ Below are a list of proposals sorted by their proposal number. See * [`340-packed-and-fragmented.md`](/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages [OPEN] * [`341-better-oos.md`](/proposals/341-better-oos.md): A better algorithm for out-of-sockets eviction [OPEN] * [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime [DRAFT] +* [`343-rend-caa.txt`](/proposals/343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification [OPEN]
diff --git a/proposals/README.md b/proposals/README.md index 0461d6a..e40bfff 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -41,6 +41,7 @@ for discussion. * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries * [`340-packed-and-fragmented.md`](/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages * [`341-better-oos.md`](/proposals/341-better-oos.md): A better algorithm for out-of-sockets eviction +* [`343-rend-caa.txt`](/proposals/343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification
## ACCEPTED proposals: slated for implementation @@ -107,7 +108,6 @@ discussion. * [`294-tls-1.3.txt`](/proposals/294-tls-1.3.txt): TLS 1.3 Migration * [`316-flashflow.md`](/proposals/316-flashflow.md): FlashFlow: A Secure Speed Test for Tor (Parent Proposal) * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits -* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience * [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime
@@ -125,6 +125,7 @@ certain changes. * [`279-naming-layer-api.txt`](/proposals/279-naming-layer-api.txt): A Name System API for Tor Onion Services * [`291-two-guard-nodes.txt`](/proposals/291-two-guard-nodes.txt): The move to two guard nodes * [`317-secure-dns-name-resolution.txt`](/proposals/317-secure-dns-name-resolution.txt): Improve security aspects of DNS name resolution +* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting
## NEEDS-RESEARCH proposals: blocking on research