tor-commits August 2013

tor-commits@lists.torproject.org

19 participants
1224 discussions

r26301: {website} bump versions for the pt tbb (website/trunk/include)
by Roger Dingledine 12 Aug '13

12 Aug '13

Author: arma Date: 2013-08-12 20:11:08 +0000 (Mon, 12 Aug 2013) New Revision: 26301 Modified: website/trunk/include/versions.wmi Log: bump versions for the pt tbb Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2013-08-12 12:45:03 UTC (rev 26300) +++ website/trunk/include/versions.wmi 2013-08-12 20:11:08 UTC (rev 26301) @@ -33,7 +33,7 @@ <define-tag version-torbrowser-vidalia whitespace=delete>0.2.21</define-tag> <define-tag version-torimbrowserbundle whitespace=delete>1.3.21</define-tag> <define-tag version-torbrowserbundlealpha whitespace=delete>2.4.15-beta-2</define-tag> -<define-tag version-torobfsbundlealpha whitespace=delete>2.4.12-alpha-2-pt1</define-tag> +<define-tag version-torobfsbundlealpha whitespace=delete>2.4.15-beta-2-pt1</define-tag> <define-tag version-torbrowserbundlelinux32 whitespace=delete>2.3.25-11</define-tag> <define-tag version-torbrowserbundlelinux64 whitespace=delete>2.3.25-11</define-tag> @@ -44,8 +44,8 @@ <define-tag version-gnu-torbrowser-vidalia whitespace=delete>0.2.21</define-tag> <define-tag version-torbrowserbundlelinux32alpha whitespace=delete>2.4.15-beta-2</define-tag> <define-tag version-torbrowserbundlelinux64alpha whitespace=delete>2.4.15-beta-2</define-tag> -<define-tag version-torobfsbundlelinux32alpha whitespace=delete>2.4.12-alpha-2-pt1</define-tag> -<define-tag version-torobfsbundlelinux64alpha whitespace=delete>2.4.12-alpha-2-pt1</define-tag> +<define-tag version-torobfsbundlelinux32alpha whitespace=delete>2.4.15-beta-2-pt1</define-tag> +<define-tag version-torobfsbundlelinux64alpha whitespace=delete>2.4.15-beta-2-pt1</define-tag> <define-tag version-torbrowserbundleosx32 whitespace=delete>2.3.25-11</define-tag> <define-tag version-torbrowserbundleosx64 whitespace=delete>2.3.25-11</define-tag> @@ -55,8 +55,8 @@ <define-tag version-osx-torbrowser-vidalia whitespace=delete>0.2.21</define-tag> <define-tag version-torbrowserbundleosx32alpha whitespace=delete>2.4.15-beta-2</define-tag> <define-tag version-torbrowserbundleosx64alpha whitespace=delete>2.4.15-beta-2</define-tag> -<define-tag version-torobfsbundleosx32alpha whitespace=delete>2.4.12-alpha-2-pt1</define-tag> -<define-tag version-torobfsbundleosx64alpha whitespace=delete>2.4.12-alpha-2-pt1</define-tag> +<define-tag version-torobfsbundleosx32alpha whitespace=delete>2.4.15-beta-2-pt1</define-tag> +<define-tag version-torobfsbundleosx64alpha whitespace=delete>2.4.15-beta-2-pt1</define-tag> <define-tag version-vidalia-stable whitespace=delete>0.2.21</define-tag> <define-tag version-vidalia-alpha whitespace=delete>0.3.1</define-tag>

1 0

[torspec/master] 219-expanded-dns: finish my edits
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit 6808038c35e960c611876b31a25761d6d9392e7d Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Aug 2 13:16:08 2013 -0400 219-expanded-dns: finish my edits These are mainly about how to normalize requests and responses, plus a few security notes. --- proposals/219-expanded-dns.txt | 43 ++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index 83bc42a..07bd38d 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -54,7 +54,7 @@ Status: Draft [XXXX We need to specify the exact behavior here: saying "Just do what Libunbound does!" would make it impossible to implement a - Tor-compatible client without reverse-engineering libunbound.] + Tor-compatible client without reverse-engineering libunbound. - NM] The FLAGS field is reserved, and should be set to 0 by all clients. @@ -89,8 +89,10 @@ Status: Draft cells, with contents: [00 04 00] R2[0:495], [00] R2[495:992], and [01] R2[992:1024] respectively. + The server should + [NOTE: I'm using the length field and the is-this-the-last-cell - field to allow multi-packet responses in the future.] + field to allow multi-packet responses in the future. -NM] AXFR and IXRF are not supported in this cell by design (see specialized tool below in section 5). @@ -107,28 +109,38 @@ Status: Draft 2. Interfaces to applications - DNSPort evdns - existing implementation will be updated to use DNS_BEGIN. + DNSPort evdns - existing implementation will be updated to use + DNS_BEGIN. + + [XXXX we should add a dig-like tool that can work over the socksport + via some extension, as tor-resolve does now. -NM] 3. Limitations on DNS query - Query class is limited to IN (INTERNET) since the only other useful class - CHAOS is practical for directly querying authoritative servers (OR in this - case acts as a recursive resolver). Query for class other than IN will - return REFUSED in the inner DNS packet. + Clients must only set query class to IN (INTERNET), since the only + other useful class CHAOS is practical for directly querying + authoritative servers (OR in this case acts as a recursive resolver). + Servers MUST return REFUSED for any for class other than IN. - Multiple questions in a single packet are not supported and OR will respond - with REFUSED as the DNS error code. + Multiple questions in a single packet are not supported and OR will + respond with REFUSED as the DNS error code. All query RR types are allowed. [XXXX I originally thought about some exit policy like "basic RR types" and "all RRs", but managing such list in deployed nodes with extra directory - flags outweighs the benefit. Maybe disallow ANY RR type? ] + flags outweighs the benefit. Maybe disallow ANY RR type? -OM] - Client as well as OR MUST block attempts to resolve local RFC 1918, 4193, - 4291 adresses (PTR). REFUSED will be returned as DNS error code from OR. + Client as well as OR MUST block attempts to resolve local RFC 1918, + 4193, or 4291 adresses (PTR). REFUSED will be returned as DNS error + code from OR. [XXXX Must they also refuse to report addresses that + resolve to these? -NM] - Request for special names (.onion, .exit, .noconnect) will return REFUSED. + Request for special names (.onion, .exit, .noconnect) must never be + sent, and will return REFUSED. + + The DNS transaction ID field MUST be set to zero in all requests and + replies; the stream ID field plays the same function in Tor. 4. Implementation notes @@ -187,8 +199,6 @@ Status: Draft 6. Security implications - Transaction ID is provided randomly by libunbound, no need to modify. - As proposal 171 mentions, we need mitigate circuit correlation. One solution would be keeping multiple streams to multiple exit nodes and picking one at random for DNS resolution. Other would be keeping DNS-resolving circuit open @@ -196,6 +206,9 @@ Status: Draft however means that it would probably incur additional latency since there would likely be a few cache misses on the newly selected exits. + [This needs more analysis; We need to consider the possible attacks + here. It would be good to have a way to tie requests to + SocksPorts, perhaps? -NM] 7. TTL normalization idea

1 0

[torspec/master] 219-expanded-dns: include some XXs from Ondrej
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit c6c28a04e6ca2f2ae1480a132ae8d1ddccecca00 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 12 10:37:20 2013 -0400 219-expanded-dns: include some XXs from Ondrej --- proposals/219-expanded-dns.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index 07bd38d..b43e63e 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -89,7 +89,7 @@ Status: Draft cells, with contents: [00 04 00] R2[0:495], [00] R2[495:992], and [01] R2[992:1024] respectively. - The server should + The server should {XXXXX}. [NOTE: I'm using the length field and the is-this-the-last-cell field to allow multi-packet responses in the future. -NM] @@ -136,6 +136,13 @@ Status: Draft code from OR. [XXXX Must they also refuse to report addresses that resolve to these? -NM] + [XXX I don't think so. People often use public DNS + records that map to private adresses. We can't effectively separate + "truly public" records from the ones client's dnsmasq or similar DNS + resolver returns. - OM] + + [XXX Then do you mean "must be returned as the DNS error from the OP"?] + Request for special names (.onion, .exit, .noconnect) must never be sent, and will return REFUSED.

1 0

[torspec/master] Add Ondrej's dns proposal in its original form
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit e24878466c5233a852e38dde8acc9cb6511f5538 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Aug 2 11:44:49 2013 -0400 Add Ondrej's dns proposal in its original form --- proposals/219-expanded-dns.txt | 267 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 267 insertions(+) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt new file mode 100644 index 0000000..c291984 --- /dev/null +++ b/proposals/219-expanded-dns.txt @@ -0,0 +1,267 @@ +Filename: xxx-dns-dnssec.txt +Title: Support for full DNS and DNSSEC resolution in Tor +Authors: Ondrej Mikle +Created: 4 February 2012 +Modified: 19 August 2012 +Status: Draft + +0. Overview + + Adding support for any DNS query type to Tor, as well as DNSSEC support. + +0.1. Motivation + + Many applications running over Tor need more than just resolving FQDN to + IPv4 and vice versa. Sometimes to prevent DNS leaks the applications have to + be hacked around to be supplied necessary data by hand (e.g. SRV records in + XMPP). TLS connections will benefit from planned TLSA record that provides + certificate pinning to avoid another Diginotar-like fiasco. + + DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC + API would be probably in OS libraries (e.g. libc). However that will + probably take time until it becomes widespread. + + On the Tor's side (as opposed to application's side), DNSSEC will provide + protection against DNS cache-poisoning attacks (provided that exit is not + malicious itself, but still reduces attack surface). + +1. Design + +1.1 New cells + + There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll + use DNS_BEGIN and DNS_RESPONSE for short below). + + DNS_BEGIN payload: + + DNS packet data (variable length) + + The DNS packet must be generated internally by libunbound to avoid + fingerprinting users by differences in client resolvers' behavior. + + DNS_RESPONSE payload: + + total length (2 octets) + data (variable) + + Data contains the reply DNS packet or its part if packet would not fit into + the cell. Total length describes length of complete response packet, thus + one DNS_BEGIN may be answered by multiple DNS_RESPONSE cells. + + DNS_BEGIN must use a non-zero, distinct StreamID, corresponding DNS_RESPONSE + will use the same StreamID. Similarly to RELAY_RESOLVE(D), no actual stream + is created. + + AXFR and IXRF are not supported in this cell by design (see specialized tool + below). + +2. Interfaces to applications + + DNSPort evdns - existing implementation will be updated to use DNS_BEGIN. + +3. Limitations on DNS query + + Query class is limited to IN (INTERNET) since the only other useful class + CHAOS is practical for directly querying authoritative servers (OR in this + case acts as a recursive resolver). Query for class other than IN will + return REFUSED in the inner DNS packet. + + Multiple questions in a single packet are not supported and OR will respond + with REFUSED as the DNS error code. + + All query RR types are allowed. + + [XXXX I originally thought about some exit policy like "basic RR types" and + "all RRs", but managing such list in deployed nodes with extra directory + flags outweighs the benefit. Maybe disallow ANY RR type? ] + + Client as well as OR MUST block attempts to resolve local RFC 1918, 4193, + 4291 adresses (PTR). REFUSED will be returned as DNS error code from OR. + + Request for special names (.onion, .exit, .noconnect) will return REFUSED. + +4. Implementation notes + + Client will periodically purge incomplete DNS replies. Any unexpected + DNS_RESPONSE will be dropped. + + AD flag must be zeroed out on client unless validation is performed. + + [XXXX libunbound lowlevel API, Tor+libunbound libevent loop + + libunbound doesn't publicly expose all the necessary parts of low-level API. + It can return the received DNS packet, but not let you construct a packet + and get it in wire-format, for example. + + Options I see: + + a) patch libunbound to be able feed wire-format DNS packets and add API to + obtain constructed packets instead of sending over network + + b) replace bufferevents for sockets in unbound with something like + libevent's paired bufferevents. This means that data extracted from + DNS_RESPONSE/DNS_BEGIN cells would be fed directly to some evbuffers that + would be picked up by libunbound. It could possibly result in avoiding + background thread of libunbound's ub_resolve_async running separate libevent + loop. + + c) bind to some arbitrary local address like 127.1.2.3:53 and use it as + forwarder for libunbound. The code there would pack/unpack the DNS packets + from/to libunbound into DNS_BEGIN/DNS_RESPONSE cells. It wouldn't require + modification of libunbound code, but it's not pretty either. Also the bind + port must be 53 which usually requires superuser privileges. + + Code of libunbound is fairly complex for me to see outright what would the + best approach be. + ] + +5. Separate tool for AXFR + + The AXFR tool will have similar interface like tor-resolve, but will + return raw DNS data. + + Parameters are: query domain, server IP of authoritative DNS. + + The tool will transfer the data through "ordinary" tunnel using RELAY_BEGIN + and related cells. + + This design decision serves two goals: + + - DNS_BEGIN and DNS_RESPONSE will be simpler to implement (lower chance of + bugs) + - in practice it's often useful do AXFR queries on secondary authoritative + DNS servers + + IXFR will not be supported (infrequent corner case, can be done by manual + tunnel creation over Tor if truly necessary). + +6. Security implications + + Transaction ID is provided randomly by libunbound, no need to modify. + + As proposal 171 mentions, we need mitigate circuit correlation. One solution + would be keeping multiple streams to multiple exit nodes and picking one at + random for DNS resolution. Other would be keeping DNS-resolving circuit open + only for a short time (e.g. 1-2 minutes). Randomly changing the circuits + however means that it would probably incur additional latency since there + would likely be a few cache misses on the newly selected exits. + + +7. TTL normalization idea + + A bit complex on implementation, because it requires parsing DNS packets at + exit node. + + TTL in reply DNS packet MUST be normalized at exit node so that client won't + learn what other clients queried. The normalization is done in following + way: + + - for a RR, the original TTL value received from authoritative DNS server + should be used when sending DNS_RESPONSE, trimming the values to interval + [5, 600] + - does not pose "ghost-cache-attack", since once RR is flushed from + libunbound's cache, it must be fetched anew + +8. Round trips and serialization + + Following are two examples of resolving two A records. The one for + addons.mozila.org is an example of a "common" RR without CNAME/DNAME, the + other for www.gov.cn an extreme example chained through 5 CNAMEs and 3 TLDs. + The examples below are shown for resolving that started with an empty DNS + cache. + + Note that multiple queries are made by libunbound as it tries to adjust for + the latency of network. "Standard query response" below that does not list + RR type is a negative NOERROR reply with NSEC/NSEC3 (usually reply to DS + query). + + The effect of DNS cache plays a great role - once DS/DNSKEY for root and a + TLD is cached, at most 3 records usually need to be fetched for a record + that does not utilize CNAME/DNAME (3 roundtrips for DS, DNSKEY and the + record itself if there are no zone cuts below). + + Query for addons.mozilla.org, 6 roundtrips (not counting retries): + + Standard query A addons.mozilla.org + Standard query A addons.mozilla.org + Standard query A addons.mozilla.org + Standard query A addons.mozilla.org + Standard query A addons.mozilla.org + Standard query response A 63.245.217.112 RRSIG + Standard query response A 63.245.217.112 RRSIG + Standard query response A 63.245.217.112 RRSIG + Standard query A addons.mozilla.org + Standard query response A 63.245.217.112 RRSIG + Standard query response A 63.245.217.112 RRSIG + Standard query A addons.mozilla.org + Standard query response A 63.245.217.112 RRSIG + Standard query response A 63.245.217.112 RRSIG + Standard query DNSKEY <Root> + Standard query DNSKEY <Root> + Standard query response DNSKEY DNSKEY RRSIG + Standard query response DNSKEY DNSKEY RRSIG + Standard query DS org + Standard query response DS DS RRSIG + Standard query DNSKEY org + Standard query response DNSKEY DNSKEY DNSKEY DNSKEY RRSIG RRSIG + Standard query DS mozilla.org + Standard query response DS RRSIG + Standard query DNSKEY mozilla.org + Standard query response DNSKEY DNSKEY DNSKEY RRSIG RRSIG + + Query for www.gov.cn, 16 roundtrips (not counting retries): + + Standard query A www.gov.cn + Standard query A www.gov.cn + Standard query A www.gov.cn + Standard query A www.gov.cn + Standard query A www.gov.cn + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A www.gov.cn + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A www.gov.cn + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A www.gov.chinacache.net + Standard query response CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A www.gov.cncssr.chinacache.net + Standard query response CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A www.gov.foreign.ccgslb.com + Standard query response CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A wac.0b51.edgecastcdn.net + Standard query response CNAME gp1.wac.v2cdn.net A 68.232.35.119 + Standard query A gp1.wac.v2cdn.net + Standard query response A 68.232.35.119 + Standard query DNSKEY <Root> + Standard query response DNSKEY DNSKEY RRSIG + Standard query DS cn + Standard query response + Standard query DS net + Standard query response DS RRSIG + Standard query DNSKEY net + Standard query response DNSKEY DNSKEY RRSIG + Standard query DS chinacache.net + Standard query response + Standard query DS com + Standard query response DS RRSIG + Standard query DNSKEY com + Standard query response DNSKEY DNSKEY RRSIG + Standard query DS ccgslb.com + Standard query response + Standard query DS edgecastcdn.net + Standard query response + Standard query DS v2cdn.net + Standard query response + + An obvious idea to avoid so many roundtrips is to serialize them together. + There has been an attempt to standardize such "DNSSEC stapling" [1], however + it's incomplete for the general case, mainly due to various intricacies - + proofs of non-existence, NSEC3 opt-out zones, TTL handling (see RFC 4035 + section 5). + +References: + + [1] https://www.ietf.org/mail-archive/web/dane/current/msg02823.html

1 0

[torspec/master] 219-expanded-dns: Clarify the exact packet format.
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit f2fec37de737faf303263bd93df206fd44ec42de Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Aug 2 12:50:43 2013 -0400 219-expanded-dns: Clarify the exact packet format. Also, make it a bit more extensible, in case we do get multi-packet responses working in the future. --- proposals/219-expanded-dns.txt | 60 +++++++++++++++++++++++++++++++++------- 1 file changed, 50 insertions(+), 10 deletions(-) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index dd015a6..83bc42a 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -42,28 +42,68 @@ Status: Draft There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll use DNS_BEGIN and DNS_RESPONSE for short below). +1.1.1. DNS_BEGIN + DNS_BEGIN payload: - DNS packet data (variable length) + FLAGS [2 octets] + DNS packet data (variable length, up to length of relay cell.) - The DNS packet must be generated internally by libunbound to avoid + The DNS packet must be generated internally by Tor to avoid fingerprinting users by differences in client resolvers' behavior. + [XXXX We need to specify the exact behavior here: saying "Just do what + Libunbound does!" would make it impossible to implement a + Tor-compatible client without reverse-engineering libunbound.] + + The FLAGS field is reserved, and should be set to 0 by all clients. + + Because of the maximum length of the RELAY cell, the DNS packet may + not be longer than 496 bytes. [XXXX Is this enough?] + + Some fields in the query must be omitted or set to zero: see section 3 + below. + +1.1.2. DNS_RESPONSE + DNS_RESPONSE payload: + STATUS [1 octet] + CONTENT [variable, up to length of relay cell] + + If the low bit of STATUS is set, this is the last DNS_RESPONSE that + the server will send in response to the given DNS_BEGIN. Otherwise, + there will be more DNS_RESPONSE packets. The other bits are reserved, + and should be set to zero for now. + + The CONTENT fields of the DNS_RESPONSE cells contain a DNS record, + split across multiple cells as needed, encoded as: + + total length (2 octets) data (variable) - Data contains the reply DNS packet or its part if packet would not fit into - the cell. Total length describes length of complete response packet, thus - one DNS_BEGIN may be answered by multiple DNS_RESPONSE cells. + So for example, if the DNS record R1 is only 300 bytes long, then it + is sent in a single DNS_RESPONSE cell with payload [01 01 2C] R1. But + if the DNS record R2 is 1024 bytes long, it's sent in 3 DNS_RESPONSE + cells, with contents: [00 04 00] R2[0:495], [00] R2[495:992], and + [01] R2[992:1024] respectively. + + [NOTE: I'm using the length field and the is-this-the-last-cell + field to allow multi-packet responses in the future.] + + AXFR and IXRF are not supported in this cell by design (see + specialized tool below in section 5). + +1.1.3. Matching queries to responses. - DNS_BEGIN must use a non-zero, distinct StreamID, corresponding DNS_RESPONSE - will use the same StreamID. Similarly to RELAY_RESOLVE(D), no actual stream - is created. + DNS_BEGIN must use a non-zero, distinct StreamID. The client MUST NOT + re-use the same stream ID until it has received a complete response + from the server or a RELAY_END cell. - AXFR and IXRF are not supported in this cell by design (see specialized tool - below). + The client may cancel a DNS_BEGIN request by sending a RELAY_END cell. + The server may refused to answer, or abort answering, a DNS_BEGIN cell + by sending a RELAY_END cell. 2. Interfaces to applications

1 0

[torspec/master] 219-expanded-dns: Isolate the references to DNSSEC
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit 0e39d9e3b953a55e9ee57d454c8d8c1ae6bcf5bd Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Aug 2 11:55:19 2013 -0400 219-expanded-dns: Isolate the references to DNSSEC This was originally a DNSSEC proposal, but the round trip issue makes it look as though this proposal is not sufficient to implement DNSSEC for practical use. --- proposals/219-expanded-dns.txt | 42 ++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index c291984..dd015a6 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -1,13 +1,13 @@ -Filename: xxx-dns-dnssec.txt +Filename: 219-expanded-dns.txt Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 -Modified: 19 August 2012 +Modified: 2 August 2013 Status: Draft 0. Overview - Adding support for any DNS query type to Tor, as well as DNSSEC support. + Adding support for any DNS query type to Tor. 0.1. Motivation @@ -17,13 +17,23 @@ Status: Draft XMPP). TLS connections will benefit from planned TLSA record that provides certificate pinning to avoid another Diginotar-like fiasco. - DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC - API would be probably in OS libraries (e.g. libc). However that will - probably take time until it becomes widespread. +0.2. What about DNSSEC? - On the Tor's side (as opposed to application's side), DNSSEC will provide - protection against DNS cache-poisoning attacks (provided that exit is not - malicious itself, but still reduces attack surface). + Routine DNSSEC resolution is not practical with this proposal alone, + because of round-trip issues: a single name lookup can require + dozens of round trips across a circuit, rendering it very slow. (We + don't want to add minutes to every webpage load time!) + + For records like TLSA that need extra signing, this might not be an + unacceptable amount of overhead, but routine hostname lookup, it's + probably overkill. + + [Further, thanks to the changes of proposal 205, DNSSEC for routine + hostname lookup is less useful in Tor than it might have been back + when we cached IPv4 and IPv6 addresses and used them across multiple + circuits and exit nodes.] + + See section 8 below for more discussion of DNSSEC issues. 1. Design @@ -162,7 +172,19 @@ Status: Draft - does not pose "ghost-cache-attack", since once RR is flushed from libunbound's cache, it must be fetched anew -8. Round trips and serialization +8. DNSSEC notes + +8.1. Where to do the resolution? + + DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC + API would be probably in OS libraries (e.g. libc). However that will + probably take time until it becomes widespread. + + On the Tor's side (as opposed to application's side), DNSSEC will provide + protection against DNS cache-poisoning attacks (provided that exit is not + malicious itself, but still reduces attack surface). + +8.2. Round trips and serialization Following are two examples of resolving two A records. The one for addons.mozila.org is an example of a "common" RR without CNAME/DNAME, the

1 0

[torspec/master] Tweak 219 a little more
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit f6d98d50c9f4b25ca190fd3242007721656b580d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 12 10:46:08 2013 -0400 Tweak 219 a little more --- proposals/219-expanded-dns.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index b43e63e..76e7987 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -3,6 +3,7 @@ Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 Modified: 2 August 2013 +Target: 0.2.5.x Status: Draft 0. Overview @@ -59,7 +60,7 @@ Status: Draft The FLAGS field is reserved, and should be set to 0 by all clients. Because of the maximum length of the RELAY cell, the DNS packet may - not be longer than 496 bytes. [XXXX Is this enough?] + not be longer than 496 bytes. [XXXX Is this enough? -NM] Some fields in the query must be omitted or set to zero: see section 3 below. @@ -89,8 +90,6 @@ Status: Draft cells, with contents: [00 04 00] R2[0:495], [00] R2[495:992], and [01] R2[992:1024] respectively. - The server should {XXXXX}. - [NOTE: I'm using the length field and the is-this-the-last-cell field to allow multi-packet responses in the future. -NM]

1 0

[torspec/master] Add an Ed25519 identities proposal and a kill-create_fast proposal
by nickm＠torproject.org 12 Aug '13

12 Aug '13

commit d909cff98e419d0d168124a6d09e88ec7d8ec136 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 12 15:17:13 2013 -0400 Add an Ed25519 identities proposal and a kill-create_fast proposal --- proposals/000-index.txt | 6 + proposals/220-ecc-id-keys.txt | 518 ++++++++++++++++++++++++++++++ proposals/221-stop-using-create-fast.txt | 90 ++++++ 3 files changed, 614 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index eaa103c..8c2d844 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -139,6 +139,9 @@ Proposals by number: 216 Improved circuit-creation key exchange [CLOSED] 217 Tor Extended ORPort Authentication [OPEN] 218 Controller events to better understand connection/circuit usage [OPEN] +219 Support for full DNS and DNSSEC resolution in Tor [DRAFT] +220 Migrate server identity keys to Ed25519 [DRAFT] +221 Stop using CREATE_FAST [OPEN] Proposals by status: @@ -153,6 +156,8 @@ Proposals by status: 182 Credit Bucket 195 TLS certificate normalization for Tor 0.2.4.x [for 0.2.4.x] 203 Avoiding censorship by impersonating an HTTPS server + 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] + 220 Migrate server identity keys to Ed25519 [for 0.2.5.x] NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret @@ -186,6 +191,7 @@ Proposals by status: 215 Let the minimum consensus method change with time 217 Tor Extended ORPort Authentication [for 0.2.5.x] 218 Controller events to better understand connection/circuit usage [for 0.2.5.x] + 221 Stop using CREATE_FAST [for 0.2.5.x] ACCEPTED: 140 Provide diffs between consensuses 147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.4.x] diff --git a/proposals/220-ecc-id-keys.txt b/proposals/220-ecc-id-keys.txt new file mode 100644 index 0000000..1c112b9 --- /dev/null +++ b/proposals/220-ecc-id-keys.txt @@ -0,0 +1,518 @@ +Filename: 220-ecc-id-keys.txt +Title: Migrate server identity keys to Ed25519 +Authors: Nick Mathewson +Created: 12 August 2013 +Target: 0.2.5.x +Status: Draft + + [Note: This is a draft proposal; I've probably made some important + mistakes, and there are parts that need more thinking. I'm + publishing it now so that we can do the thinking together.] + +0. Introduction + + In current Tor designs, identity keys are limited to 1024-bit RSA + keys. + + Clearly, that should change, because RSA doesn't represent a good + performance-security tradeoff nowadays, and because 1024-bit RSA is + just plain too short. + + We've already got an improved circuit extension handshake protocol + that uses curve25519 in place of RSA1024, and we're using (where + supported) P256 ECDHE in our TLS handshakes, but there are more uses + of RSA1024 to replace, including: + + * Router identity keys + * TLS link keys + * Hidden service keys + + This proposal describes how we'll migrate away from using 1024-bit + RSA in the first two, since they're tightly coupled. Hidden service + crypto changes will be complex, and will merit their own proposal. + + In this proposal, we'll also (incidentally) be extirpating a number + of SHA1 usages. + +1. Overview + + When this proposal is implemented, every router will have an Ed25519 + identity key in addition to its current RSA1024 public key. + + Ed25519 (specifically, Ed25519-SHA-512 as described and specified at + http://ed25519.cr.yp.to/) is a desirable choice here: it's secure, + fast, has small keys and small signatures, is bulletproof in several + important ways, and supports fast batch verification. (It isn't quite + as fast as RSA1024 when it comes to public key operations, since RSA + gets to take advantage of small exponents when generating public + keys.) + + (For reference: In Ed25519 public keys are 32 bytes long, private keys + are 64 bytes long, and signatures are 64 bytes long.) + + To mirror the way that authority identity keys work, we'll fully + support keeping Ed25519 identity keys offline; they'll be used to + sign long-ish term signing keys, which in turn will do all of the + heavy lifting. A signing key will get used to sign the things that + RSA1024 identity keys currently sign. + +1.1. 'Personalized' signatures + + Each of the keys introduced here is used to sign more than one kind + of document. While these documents should be unambiguous, I'd going + to forward-proof the signatures by specifying each signature to be + generated, not on the document itself, but on the document prefixed + with some distinguishing string. + +2. Certificates and Router descriptors. + +2.1. Certificates + + When generating a signing key, we also generate a certificate for it. + Unlike the certificates for authorities' signing keys, these + certificates need to be sent around frequently, in significant + numbers. So we'll choose a compact representation. + + VERSION [1 Byte] + TYPE [1 Byte] + CERTIFIED_KEY [32 Bytes] + EXPIRATION_DATE [4 Bytes] + EXTRA_STUFF [variable length] + SIGNATURE [64 Bytes] + + The "VERSION" field holds the value [01]. The "TYPE" field holds the + value [01]. The CERTIFIED_KEY field is an Ed25519 public key. The + expiration date is a day, given in DAYS since the epoch, after which + this certificate isn't valid. The EXTRA_STUFF field is left for a + future version of this format. + + [XXXX Is "EXTRA_STUFF" a good idea? -NM] + + Before processing any certificate, parties MUST know which identity + key it is supposed to be signed by, and then check the signature. + The signature is formed by signing the first N-64 bytes of the + certificate prefixed with the string "Tor node signing key + certificate v1". + + We also specify a revocation document for revoking a signing key or an + identity key. Its format is: + FIXED_PREFIX [8 Bytes] + VERSION [1 Byte] + KEYTYPE [1 Byte] + IDENTITY_KEY [32 Bytes] + REVOKED_KEY [32 Bytes] + PUBLISHED [8 Bytes] + EXTRA_STUFF [variable length] + SIGNATURE [64 Bytes] + + FIXED_PREFIX is "REVOKEID" or "REVOKESK". VERSION is [01]. KEYTYPE is + [01] for revoking a signing key or [02] or revoking an identity key. + REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's + Ed25519 identity key. PUBLISHED is the time that the document was + generated, in seconds since the epoch. EXTRA_STUFF is left for a + future version of this document. The SIGNATURE is generated with + the same key as in IDENTITY_KEY, and covers the entire revocation, + prefixed with "Tor key revocation v1". + + Using these revocation documents is unspecified. + +2.2. Managing keys + + By default, we can keep the easy-to-setup key management properties + that Tor has now, so that node operators aren't required to have + offline public keys: + + * When a Tor node starts up with no Ed25519 identity keys, it + generates a new identity keypair. + * When a Tor node has an Ed25519 identity keypair, and it has + no signing key, or its signing key is going to expire within + the next 48 hours, it generates a new signing key to last + 30 days. + + But we also support offline identity keys: + + * When a Tor node starts with an Ed25519 public identity key + but no private identity key, it checks wither it has + a currently valid certified signing keypair. If it does, + it starts. Otherwise, it refuses to start. + * If a Tor node's signing key is going to expire soon, it starts + warning the user. If it is expired, then the node shuts down. + +2.3. Router descriptors + + We specify the following element that may appear at most once in + each router descriptor: + "identity-ed25519" SP identity-key SP certification NL + + The identity-key and certification are base64 encoded with + terminating =s removed. When this element is present, it MUST appear + as the first or second element in the router descriptor. + + [XXX The rationale here is to allow extracting the identity key and + signing key and checking the signature before fully parsing the rest + of the document. -NM] + + When an identity-ed25519 element is present, there must also be an + "router-signature-ed25519" element. It MUST be the next-to-last + element in the descriptor, appearing immediately before RSA + signature. It MUST contain an ed25519 signature of the entire + document, from the first character up to but not including the + "router-signature-ed25519" element, prefixed with the string "Tor + router descriptor signature v1". Its format is: + + "router-signature-ed25519" SP signature NL + + Were 'signature' is encoded in base64 with terminating =s removed. + + The identity key in the identity-ed25519 key MUST be the one used to + sign the certification, and the signing key in the certification MUST + be the one used to sign the document. + + + Note that these keys cross-certify as follows: the ed25519 identity + key signs the ed25519 signing key in the certificate. The ed25519 + signing key signs itself and the ed25519 identity key and the RSA + identity key as part of signing the descriptor. And the RSA identity + key also signs all three keys as part of signing the descriptor. + + +2.3.1. Checking descriptor signatures. + + Current versions of Tor will handle these new formats by ignoring the + new fields, and not checking any ed25519 information. + + New version of Tor will have a flag that tells them whether to check + ed25519 information. When it is set, they must check: + + * All RSA information and signatures that Tor implementations + currently check. + * If the identity-ed25519 line is present, it must be well-formed, + and the certificate must be well-formed and correctly signed, + and there must be a valid. + * If we require an ed25519 key for this node (see 3.1 below), the + ed25519 key must be present. + + Authorities and directory caches will have this flag always-on. For + clients, it will be controlled by a torrc option and consensus + option, to be set to "always-on" in the future once enough clients + support it. + +2.3.2. Extra-info documents + + Extrainfo documents now include "identity-ed25519" and + "router-signature-ed25519" fields in the same positions in which they + appear in router descriptors. + + Additionally, we add the base64-encoded, =-stripped SHA256 digest of + a node's extra-info document field to the extra-info-digest line. + (All versions of Tor that recognize this line allow an extra field + there.) + +2.3.3. A note on signature verification + + Here and elsewhere, we're receiving a certificate and a document + signed with the key certified by that certificate in the same step. + This is a fine time to use the batch signature checking capability of + Ed25519, so that we can check both signatures at once without (much) + additional overhead over checking a single signature. + +3. Consensus documents and authority operation + +3.1. Handling router identity at the authority + + When receiving router descriptors, authorities must track mappings + between RSA and Ed25519 keys. + + Rule 1: Once an authority has seen an Ed25519 identity key and an RSA + identity key together on the same (valid) descriptor, it should no + longer accept any descriptor signed by that RSA key with a different + Ed25519 key, or that Ed25519 key with a different RSA key. + + Rule 2: Once an authority has seen an Ed25519 identity key and an RSA + identity key on the same descriptor, it should no longer accept any + descriptor signed by that RSA key unless it also has that Ed25519 + key. + + + These rules together should enforce the property that, even if an + attacker manages to steal or factor a node's RSA identity key, the + attacker can't impersonate that node to the authorities, even when + that node is identified by its RSA key. + + + Enforcement of Rule 1 should be advisory-only for a little while (a + release or two) while node operators get experience having Ed25519 + keys, in case there are any bugs that cause or force identity key + replacement. Enforcement of Rule 2 should be advisory-only for + little while, so that node operators can try 0.2.5 but downgrade to + 0.2.4 without being de-listed from the consensus. + + + [XXX I could specify a way to do a signed "I'm downgrading for a + while!" statement, and kludge some code back into 0.2.4.x to better + support that?] + +3.2. Formats + + Vote and consensus documents now contain an optional "id" field for each + routerstatus section. Its format is: + + "id" SP ed25519-identity NL + + where ed25519-identity is base-64 encoded, with trailing = characters + omitted. In vote documents, it may be replaced by the format: + + "id" SP "none" NL + + which indicates that the node does not have an ed25519 identity. (In + the consensus, a lack of "id" line means that the node has no ed25519 + identity.) + + [XXXX Should the id entries in consensuses go into microdescriptors + instead? I think perhaps so. -NM] + + A vote or consensus document is ill-formed if it includes the same + ed25519 identity key twice. + +3.3. Generating votes + + An authority should pick which descriptor to choose for a node as + before, and include the ed25519 identity key for the descriptor if + it's present. + + As a transition, before Rule 1 and Rule 2 in 3.1 are fully enforced, + authorities need a way to deal with the possibility that there might + be two nodes with the same ed25519 key but different RSA keys. In + that case, it votes for the one with the most recent publication + date. + + (The existing rules already prevent an authority from voting for two + servers with the same RSA identity key.) + +3.4. Generating a consensus from votes + + This proposal requires a new consensus vote method. When we deploy + it, we'll pick the next available vote method in sequence to use for + this. + + When the new consensus method is in use, we must choose nodes first + by ECC key, then by RSA key. + + First, for every {ECC identity key, RSA identity key} pair listed by + over half of the voting authorities, list it, unless some other RSA + identity key digest is listed more popularly for the ECC key. Break + ties in favor of low RSA digests. Treat all routerstatus entries that + mention this <ECC,RSA> pair as being for the same router, and all + routerstatus entries that mention the same RSA key with an + unspecified ECC key as being for the same router. + + Then, for every node that has previously not been listed, perform the + current routerstatus algorithm: listing a node if it has been listed + by at least N/2 voting authorities, and treating all routerstatuses + containing the same identity as the same router. + + In other words: + + Let Entries = [] + + for each ECC ID listed by any voter: + Find the RSA key associated with that ECC ID by the most voters, + breaking ties in favor of low RSA keys. + + If that ECC ID and RSA key ID are listed by > N/2 voting authorities: + Add the consensus of the routerstatus entries for those + voters, along with the routerstatus entry for every voter + that included that RSA key with no ECC key, to Entries. + Include the ECC ID in the consensus. + + For each RSA key listed by any voter: + If that RSA key is already in Entries, skip it. + + If the RSA key is listed by > N/2 voting authorities: + Add the consensus of the routerstatus entries for those + voters to Entries. Do not include an ECC key in the + consensus. + + [XXX Think about this even more.] + +4. The link protocol + + [XXX This section won't make much sense unless you grok the v3 + connection protocol as described in tor-spec.txt, first proposed in + proposal 195.] + + We add four new CertType values for use in CERTS cells: + 4: Ed25519 signing key + 5: Link key certificate certified by Ed25519 signing key + 6: TLS authentication key certified by Ed25519 signing key + 7: RSA cross-certification for Ed25519 identity key + + The content of certificate type 4 is: + Ed25519 identity key [32 byets] + Signing key certificate as in 2.1 above [variable length] + + The content of certificate type 5 is: + CERT_DIGEST [32 bytes] + EXPIRATION_DATE [4 bytes] + EXTRA_STUFF [variable] + SIGNATURE [64 bytes] + where CERT_DIGEST is a SHA256 digest of the X.509 certificate used + for the TLS link, EXPIRATION_DATE is a date in *days* since the epoch + starting on which the certificate is invalid, and SIGNATURE is + a signature using the signing key of the above two fields, prefixed + with "Tor TLS link certificate check v1". + + The content of certificate type 6 is the same as the signing key in + 2.1 above, except that the TYPE field is 02 and the fixed string used + in signing is "". The Ed25519 key + certified by this key can be used in AUTHENTICATE cells. + + The content of certificate type 7 is: + ED25519_KEY [32 bytes] + EXPIRATION_DATE [4 bytes] + SIGNATURE [128 bytes] + Here, the Ed25519 identity key is signed with router's identity key, + to indicate that authenticating with a key certified by the Ed25519 + key counts as certifying with RSA identity key. (The signature is + computed on the SHA256 hash of the non-signature parts of the + certificate, prefixed with the string "Tor TLS RSA/Ed25519 + cross-certification".) + + (There's no reason to have a corresponding Ed25519-signed-RSA-key + certificate here, since we do not treat authenticating with an RSA + key as proving ownership of the Ed25519 identity.) + + Relays with Ed25519 keys should always send these certificate types + in addition to their other certificate types. + + Non-bridge relays with Ed25519 keys should generate TLS link keys of + appropriate strength, so that the certificate chain from the Ed25519 + key to the link key is strong enough. + + + We add a new authentication type for AUTHENTICATE cells: + "Ed25519-TLSSecret", with AuthType value 2. Its format is the same as + "RSA-SHA256-TLSSecret", except that the CID and SID fields support + more key types; some strings are different, and the signature is + performed with Ed25519 using the authentication key from a type-6 + cert. + + TYPE: The characters "AUTH0002" [8 octets] + CID: A SHA256 hash of the initiator's RSA1024 identity key [32 octets] + SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets] + CID_ED: The initiator's Ed25519 identity key [32 octets] + SID_ED: The responder's Ed25519 identity key, or all-zero. [32 octets] + SLOG: A SHA256 hash of all bytes sent from the responder to the + initiator as part of the negotiation up to and including the + AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell, + the AUTH_CHALLENGE cell, and any padding cells. [32 octets] + CLOG: A SHA256 hash of all bytes sent from the initiator to the + responder as part of the negotiation so far; that is, the + VERSIONS cell and the CERTS cell and any padding cells. [32 + octets] + SCERT: A SHA256 hash of the responder's TLS link certificate. [32 + octets] + TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the + secret key, of the following: + - client_random, as sent in the TLS Client Hello + - server_random, as sent in the TLS Server Hello + - the NUL terminated ASCII string: + "Tor V3 handshake TLS cross-certification with Ed25519" + [32 octets] + TIME: The time of day in seconds since the POSIX epoch. [8 octets] + RAND: A 16 byte value, randomly chosen by the initiator. [16 octets] + SIG: A signature of all previous fields using the initiator's + Ed25519 authentication flags. + [variable length] + + + If you've got a consensus that lists an ECC key for a node, but the + node doesn't give you an ECC key, then refuse this connection. + +5. The extend protocol + + We add a new NSPEC node specifier for use in EXTEND2 cells, with + LSTYPE value [03]. Its length must be 32 bytes; its content is the + Ed25519 identity key of the target node. + + Clients should use this type only when: + * They know an Ed25519 identity key for the destination node. + * The source node supports EXTEND2 cells + * A torrc option is set, _or_ a consensus value is set. + + We'll leave the consensus value off for a while until more clients + support this, and then turn it on. + + When picking a channel for a circuit, if this NSPEC value is + provided, then the RSA identity *and* the Ed25519 identity must + match. + + If we have a channel with a given Ed25519 ID and RSA identity, and we + have a request for that Ed25519 ID and a different RSA identity, we + do not attempt to make another connection: we just fail and DESTROY + the circuit. + + If we receive an EXTEND or EXTEND2 request for a node listed in the + consensus, but that EXTEND/EXTEND2 request does not include an + Ed25519 identity key, the node SHOULD treat the connection as failed + if the Ed25519 identity key it receives does not match the one in the + consensus. + +6. Naming nodes in the interface + + Anywhere in the interface that takes an $identity should be able to + take an ECC identity too. ECC identities are case-sensitive base64 + encodings of Ed25519 identity keys. You can use $ to indicate them as + well; we distinguish RSA identity digests length. + + When we need to indicate an Ed25519 identity key in an hostname + format (as in a .exit address), we use the lowercased version of the + name, and perform a case-insensitive match. (This loses us one bit + per byte of name, + + Nodes must not list Ed25519 identities in their family lines; clients + and authorities must not honor them there. + + Clients shouldn't accept .exit addresses with Ed25519 names on SOCKS + or DNS ports by default, even when AllowDotExit is set. + + We need an identity-to-node map for ECC identity and for RSA + identity. + + The controller interface will need to accept and report Ed25519 + identity keys as well as (or instead of) RSA identity keys. That's a + separate proposal, though. + +7. Hidden service changes out of scope + + Hidden services need to be able identity nodes by ECC keys, just as + they will need to include ntor keys as well as TAP keys. Not just + yet though. This needs to be part of a bigger hidden service + revamping strategy. + +8. Proposed migration steps + + Once a few versions have shipped with Ed25519 key support, turn on + "Rule 1" on the authorities. (Don't allow an Ed25519<->RSA pairing + to change.) + + Once 0.2.5.x is in beta or rc, turn on the consensus option for + everyone who receives descriptors with Ed25519 identity keys to check + them. + + Once 0.2.5.x is in beta or rc, turn on the consensus option for + clients to generate EXTEND2 requests with Ed25519 identity keys. + + Once 0.2.5.x has been stable for a month or two, turn on "Rule 2" on + authorities. (Don't allow nodes that have advertised an Ed25519 key + to stop.) + +9. Future proposals + + * Ed25519 identity support on the controller interface + * Supporting nodes without RSA keys + * Remove support for nodes without Ed25519 keys + * Ed25519 support for hidden services + * Bridge identity support. + * Ed25519-aware family support + * diff --git a/proposals/221-stop-using-create-fast.txt b/proposals/221-stop-using-create-fast.txt new file mode 100644 index 0000000..26ba5b7 --- /dev/null +++ b/proposals/221-stop-using-create-fast.txt @@ -0,0 +1,90 @@ +Filename: 221-stop-using-create-fast.txt +Title: Stop using CREATE_FAST +Authors: Nick Mathewson +Created: 12 August 2013 +Target: 0.2.5.x +Status: Open + +0. Summary + + I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST + cells, and use CREATE or CREATE2 cells instead as appropriate. + +1. Introduction + + The CREATE_FAST cell was created to avoid the performance hit of + using the TAP handshake on a TLS session that already provided what + TAP provided: authentication with RSA1024 and forward secrecy with + DH1024. But thanks to the introduction of the ntor onionskin + handshake in Tor 0.2.4.x, for nodes with older versions of OpenSSL, + the TLS handshake strength lags behind with the strength of the onion + handshake, and the arguments against CREATE no longer apply. + + Similarly, it's good to have an argument for circuit security that + survives possible breakdowns in TLS. But when CREATE_FAST is in use, + this is impossible: we can only argue forward-secrecy at the first + hop of each circuit by assuming that TLS has succeeded. + + So let's simply stop sending CREATE_FAST cells. + +2. Proposed design + + Currently, only clients will send CREATE_FAST, and only when they + have FastFirstHopPK set to its default value, 1. + + I propose that we change "FastFirstHopPK" from a boolean to also + allow a new default "auto" value that tells Tor to take a value from + the consensus. I propose a new consensus parameter, "usecreatefast", + default value taken to be 1. + + Once enough versions of Tor support this proposal, the authorities + should set the value for "usecreatefast" to be 0. + + In the series after that (0.2.6.x?), the default value for + "FastFirstHopPK" should be 0. + + (Note that CREATE_FAST must still be used in the case where a client + has connected to a guard node or bridge without knowing any onion + keys for it, and wants to fetch directory information from it.) + +3. Alternative designs + + We might make some choices to preserve CREATE_FAST under some + circumstances. For example, we could say that CREATE_FAST is okay if + we have a TLS connection with a cipher, public key, and ephemeral key + algorithm of a given strength. + + We might try to trust the TLS handshake for authentication but not + forward secrecy, and come up with a first-hop handshake that did a + simple curve25519 diffie-hellman. + + We might use CREATE_FAST only whenever ntor is not available. + + I'm rejecting all of the above for complexity reasons. + + We might just change the default for FastFirstHopPK to 1 in + 0.2.5.x-alpha. It would make early users of that alpha easy for + their guards to distinguish. + +4. Performance considerations + + This will increase the CPU requirements on guard nodes; their + cpuworkers would be more heavily loaded as 0.2.5.x is more + adopted. + + I believe that, if guards upgrade to 0.2.4.x as 0.2.5.x is under + development, the commensurate benefits of ntor will outweigh the + problems here. This holds even more if we wind up with a better ntor + implementation or replacement. + +5. Considerations on client detection + + Right now, in a few places, Tor nodes assume that any connection on + which they have received a CREATE_FAST cell is probably from a + non-relay node, since relays never do that. Implementing this + proposal would make that signal unreliable. + + We should do this proposal anyway. CREATE_FAST has never been a + reliable signal, since "FastFirstHopPK 0" is easy enough to type, and + the source code is easy enough to edit. Proposal 163 and its + successors have better ideas here anyway.

1 0

[translation/liveusb-creator] Update translations for liveusb-creator
by translation＠torproject.org 12 Aug '13

12 Aug '13

commit 87d84b7f1430a51462bdb86b8900a82cd69a5c6e Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 12 16:46:16 2013 +0000 Update translations for liveusb-creator --- ca/ca.po | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ca/ca.po b/ca/ca.po index c0b8275..e4f5c6f 100644 --- a/ca/ca.po +++ b/ca/ca.po @@ -4,13 +4,14 @@ # # Translators: # Nyek <electromigracion(a)gmail.com>, 2013 +# Nyek <electromigracion(a)gmail.com>, 2013 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2013-08-07 16:08+0200\n" -"PO-Revision-Date: 2013-08-08 09:40+0000\n" -"Last-Translator: runasand <runa.sandvik(a)gmail.com>\n" +"PO-Revision-Date: 2013-08-12 16:40+0000\n" +"Last-Translator: Nyek <electromigracion(a)gmail.com>\n" "Language-Team: Catalan (http://www.transifex.com/projects/p/torproject/language/ca/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -120,7 +121,7 @@ msgstr "" #: ../liveusb/creator.py:400 #, python-format msgid "Creating %sMB persistent overlay" -msgstr "" +msgstr "Creant una capa persistent de %sMB" #: ../liveusb/gui.py:556 msgid "" @@ -416,7 +417,7 @@ msgstr "" #: ../liveusb/creator.py:494 #, python-format msgid "Unable to remove directory from previous LiveOS: %(message)s" -msgstr "" +msgstr "Incapaç d'eliminar el directori del LiveOS previ: %(message)s" #: ../liveusb/creator.py:482 #, python-format @@ -437,7 +438,7 @@ msgstr "Incapaç de fer servir l'arxiu seleccionat. Pots tenir més sort si mou #: ../liveusb/creator.py:692 #, python-format msgid "Unable to write on %(device)s, skipping." -msgstr "" +msgstr "Incapaç d'escriure a %(device)s, passant." #: ../liveusb/creator.py:382 msgid "Unknown ISO, skipping checksum verification"

1 0

[translation/https_everywhere_completed] Update translations for https_everywhere_completed
by translation＠torproject.org 12 Aug '13

12 Aug '13

commit 44cc7dbe905fd61ef8380f8cc0077eddf3a2cdbe Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 12 16:46:14 2013 +0000 Update translations for https_everywhere_completed --- ca/https-everywhere.dtd | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/ca/https-everywhere.dtd b/ca/https-everywhere.dtd new file mode 100644 index 0000000..39f8132 --- /dev/null +++ b/ca/https-everywhere.dtd @@ -0,0 +1,37 @@ +<!ENTITY https-everywhere.about.title "Sobre HTTPS Everywhere"> +<!ENTITY https-everywhere.about.ext_name "HTTPS Everywhere"> +<!ENTITY https-everywhere.about.ext_description "Xifrar la Web! Fes servir la seguretat HTTPS a molts llocs."> +<!ENTITY https-everywhere.about.version "Versió"> +<!ENTITY https-everywhere.about.created_by "Creat per"> +<!ENTITY https-everywhere.about.librarians "C"> +<!ENTITY https-everywhere.about.thanks "Gràcies a"> +<!ENTITY https-everywhere.about.contribute "Si t'agrada HTTPS Everywhere, podries considerar"> +<!ENTITY https-everywhere.about.donate_tor "Donar a Tor"> +<!ENTITY https-everywhere.about.tor_lang_code "en"> +<!ENTITY https-everywhere.about.donate_eff "Donar a EFF"> + +<!ENTITY https-everywhere.menu.about "Sobre HTTPS Everywhere"> +<!ENTITY https-everywhere.menu.observatory "Preferències de SSL Observatory"> +<!ENTITY https-everywhere.menu.globalEnable "Activar HTTPS Everywhere"> +<!ENTITY https-everywhere.menu.globalDisable "Desactivar HTTPS Everywhere"> + +<!ENTITY https-everywhere.prefs.title "Preferències de HTTPS Everywhere"> +<!ENTITY https-everywhere.prefs.enable_all "Activar-ho tot"> +<!ENTITY https-everywhere.prefs.disable_all "Desactivar-ho tot"> +<!ENTITY https-everywhere.prefs.reset_defaults "Tornar a opcions per defecte"> +<!ENTITY https-everywhere.prefs.search "Cercar"> +<!ENTITY https-everywhere.prefs.site "Lloc"> +<!ENTITY https-everywhere.prefs.notes "Notes"> +<!ENTITY https-everywhere.prefs.list_caption "Quines regles de redirecció HTTPS vols aplicar?"> +<!ENTITY https-everywhere.prefs.enabled "Habilitat"> +<!ENTITY https-everywhere.prefs.ruleset_howto "Pots aprendre com escriure les teves pròpies regles (per afegir suport a altres webs)"> +<!ENTITY https-everywhere.prefs.here_link "aquí"> +<!ENTITY https-everywhere.prefs.toggle "Canviar"> +<!ENTITY https-everywhere.prefs.reset_default "Tornar a la opció per defecte"> +<!ENTITY https-everywhere.prefs.view_xml_source "Veure el codi XML"> + +<!ENTITY https-everywhere.source.downloading "Descarregant"> +<!ENTITY https-everywhere.source.filename "Nom d'arxiu"> +<!ENTITY https-everywhere.source.unable_to_download "Incapaç de descarregar la font."> + +

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits August 2013