[tor-commits] [torspec] branch main updated: prop343: Initial import

gitolite role git at cupani.torproject.org
Mon May 8 19:15:58 UTC 2023


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 at 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 at 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 at 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 at 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

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.


More information about the tor-commits mailing list