[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec] branch main updated: prop343: Initial import
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@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx>
---
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@xxxxxxxxxxxx>
+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@xxxxxxxxxxx";
+ 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.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits