Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W3ZJF-0000Fv-5p for bitcoin-development@lists.sourceforge.net; Wed, 15 Jan 2014 22:51:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.173 as permitted sender) client-ip=209.85.215.173; envelope-from=mh.in.england@gmail.com; helo=mail-ea0-f173.google.com; Received: from mail-ea0-f173.google.com ([209.85.215.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W3ZJD-0005aO-9h for bitcoin-development@lists.sourceforge.net; Wed, 15 Jan 2014 22:51:41 +0000 Received: by mail-ea0-f173.google.com with SMTP id o10so766059eaj.32 for ; Wed, 15 Jan 2014 14:51:33 -0800 (PST) X-Received: by 10.15.35.194 with SMTP id g42mr7209805eev.20.1389826292927; Wed, 15 Jan 2014 14:51:32 -0800 (PST) Received: from [192.168.1.102] (84-75-251-165.dclient.hispeed.ch. [84.75.251.165]) by mx.google.com with ESMTPSA id o13sm13834518eex.19.2014.01.15.14.51.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 14:51:31 -0800 (PST) Sender: Mike Hearn From: Mike Hearn Content-Type: multipart/signed; boundary="Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net> Date: Wed, 15 Jan 2014 23:51:21 +0100 To: bitcoin-development@lists.sourceforge.net Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W3ZJD-0005aO-9h Subject: [Bitcoin-development] Tor / SPV X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 22:51:41 -0000 --Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C Content-Type: multipart/alternative; boundary="Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1" --Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 intro text starts here, protocol upgrade proposal starts further down Recently on IRC we have discussed what it'd take to use SSL on P2P = connections, the goal being encryption and authentication of traffic to = help avoid passive wiretapping and sybil attacks. Gregory pointed out - very reasonably - that OpenSSL is huge and very = old-school C, meaning that using it to implement SSL would put a big = piece of code exposed to the internet into the same process as people=92s = wallets. This would be not excellent. Also, even with encryption, with = SSL you only get some resistance to traffic analysis. And it'd be a = complicated upgrade. Tor is an option, but it has other disadvantages: 1) Also a giant piece of C that is likely to contain bugs 2) Breaks our anti-sybil heuristics when connecting to hidden services 3) MITM very likely when not connecting to hidden services 4) Is not usable as a library at all. Convention to use Tor is "tell = user to start TorBrowser and connect to the SOCKS port". The latter point means in reality hardly anyone will ever connect via = Tor, as you'd have to do extra setup and most people are lazy. = Especially it's not going to work on mobile. It=92s not worth doing = something complicated if hardly anyone would use it. But recently I discovered this interesting piece of code: http://www.subgraph.com/orchid.html It is a pure Java implementation of the Tor protocol (client only, no = relays), easily usable as a library. Sure enough after about an hour of = fiddling around, I now have a bitcoinj that connects via Tor with no = other software running. Suddenly making MultiBit, the Android Bitcoin Wallet app, Hive and other = bitcoinj based wallets use Tor by default seems very plausible. So I started thinking about what it'd take to switch this on for = everyone. The biggest problem is that SPV wallets can't verify = unconfirmed/pending transactions for themselves, so they rely on = counting the number of peers that announced it and assuming that their = internet connections aren't being tampered with. Mostly this assumption = is a good one - we have never heard anyone report that they were paid = with a fake pending tx using a MITM attack. However, with Tor the chance of being MITMd goes up dramatically. Lots = of people have reported exit nodes that are doing SSL stripping. Being = sybilled when using exit nodes seems rather likely. Connecting to hidden services solve the MITM problem but screws you in a = different way. Bitcoin Core has some weak heuristics in the code to try = and ensure we don=92t accidentally connect to nodes all controlled by = the same guys =85 mostly by trying to keep a good mix of /16s. This is = probably not very hard to defeat, but it does at least raise the bar = beyond =93buy lots of amazon VMs=94. With hidden services we lose that. = Also, there aren=92t very many nodes running as hidden services - if all = bitcoinjs started hitting them simultaneously they=92d probably die. tl;dr the proposal starts here Let=92s fix this so SPV wallets can use Tor by default. Downgrading = things is not an option, it must be pure upgrade. We can do it like = this: 1) Firstly, we observe that MITM only matters when we=92re trying to = count pending transaction announcements, but most of the load SPV = wallets impose on the network is chain filtering. So it=92s OK to = download the chain from any arbitrary clearnet IP via Tor because we=92re = checking Merkle branches. This ensures we won=92t put excessive load on = hidden service nodes. 2) Secondly, we bump the protocol version, add a service flag and = introduce a new P2P protocol command =93tor?=94. If a client sends a = tor? message to a node that has the new service flag set, it will = respond with a new =93tor=94 message that contains a regular addr = packet, with a single address, the IPv6-ified version of its hidden = service name. 3) SPV wallets that want to get a good mix of nodes for measuring = pending transactions identify nodes on the clearnet via their addr = announcements+service flag, in the normal way. They select some of these = nodes using the standard clearnet anti-sybil heuristics and connect = without using Tor. They proceed to query them for their hidden service = key. After they=92ve done that, they record the public IP->hidden = service mapping and can go ahead and connect back to them at any later = time via Tor itself. This would seem to be pointless - did we not just go ahead and bypass = Tor entirely, thus making neither node hidden? Is it not a dead cert = that the next connection the node gets via Tor is likely the same = computer? Yes, but it only matters the first time. As long as those = nodes are somewhat stable the mapping will be recorded on disk and the = next time the wallet starts, it=92ll skip straight to using Tor. The goal of all that is that we get to keep our existing IPv4 based = anti-sybil heuristics, so we can=92t possibly make anything worse, only = better. Plus, we=92ve now set things up so in future if/when we come up = with a better anti-sybil system based on anonymous identities or other = fancy crypto, we can take out the =93connect via clearnet=94 step and go = straight to using hidden services with only a very small set of code = changes and no new protocol work. I like this idea for several reasons: It feels implementable to me in about a couple of weeks wall-time. The = tasks are small - the new tor? p2p message is super easy to implement = because a node already knows if it=92s a hidden service or not. On the = bitcoinj side, it=92d take a bit of work to implement the extra storage = of IPv4->onion mappings and ensure the right kind of connection is used = at the right time, but it=92s not all that hard. We could switch Tor on by default for a lot of users. On the bitcoind side, Tor runs as a separate process and because it = initiates connections to bitcoind, it can be easily sandboxed, e.g. ran = as a different UNIX user or even run inside a chroot/ptrace jail. Even = though Tor is likely to contain exploits, we can easily keep them away = from the wallet. So there=92s not much additional surface area. Obviously as it=92s pure Java and client only, Orchid is immune to = buffer overflows/double frees and other such security problems. It=92s optional for all parties. Wallet clients can try to fall back to = non-Tor usage if their access to Tor seems to be blocked somehow. Tor is the gold standard for resisting traffic analysis - we know thanks = to Snowden that it=92s good at this task. To launch I=92d probably have a percentage throttle hosted on some SSLd = website, so we can control the load placed on the existing hidden = service nodes. Feedback welcome. --Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
intro text starts here, protocol upgrade proposal starts = further down

Recently on IRC we have discussed what it'd take = to use SSL on P2P connections, the goal being encryption and = authentication of traffic to help avoid passive wiretapping and sybil = attacks.

Gregory pointed out - very = reasonably - that OpenSSL is huge and very old-school C, meaning that = using it to implement SSL would put a big piece of code exposed to the = internet into the same process as people=92s wallets. This would be not = excellent. Also, even with encryption, with SSL you only get some = resistance to traffic analysis. And it'd be a complicated = upgrade.

Tor is an option, but it has = other disadvantages:

1) Also a giant = piece of C that is likely to contain bugs
2) Breaks our = anti-sybil heuristics when connecting to hidden services
3) MITM very likely when not connecting to hidden = services
4) Is not usable as a library at all. Convention to = use Tor is "tell user to start TorBrowser and connect to the SOCKS = port".

The latter point means in reality = hardly anyone will ever connect via Tor, as you'd have to do extra setup = and most people are lazy. Especially it's not going to work on mobile. = It=92s not worth doing something complicated if hardly anyone would use = it.

But recently I discovered this = interesting piece of code:


It is a pure Java = implementation of the Tor protocol (client only, no relays), easily = usable as a library. Sure enough after about an hour of fiddling around, = I now have a bitcoinj that connects via Tor with no other software = running.

Suddenly making MultiBit, the = Android Bitcoin Wallet app, Hive and other bitcoinj based wallets use = Tor by default seems very plausible.

So I started thinking about what it'd take to switch this on for = everyone. The biggest problem is that SPV wallets can't verify = unconfirmed/pending transactions for themselves, so they rely on = counting the number of peers that announced it and assuming that their = internet connections aren't being tampered with. Mostly this assumption = is a good one - we have never heard anyone report that they were paid = with a fake pending tx using a MITM attack.

However, with Tor the chance of being MITMd goes up = dramatically. Lots of people have reported exit nodes that are doing SSL = stripping. Being sybilled when using exit nodes seems rather = likely.

Connecting to hidden services = solve the MITM problem but screws you in a different way. Bitcoin Core = has some weak heuristics in the code to try and ensure we don=92t = accidentally connect to nodes all controlled by the same guys =85 mostly = by trying to keep a good mix of /16s. This is probably not very hard to = defeat, but it does at least raise the bar beyond =93buy lots of amazon = VMs=94. With hidden services we lose that. Also, there aren=92t very = many nodes running as hidden services - if all bitcoinjs started hitting = them simultaneously they=92d probably die.

tl;dr the proposal starts here

Let=92s fix this so SPV wallets = can use Tor by default. Downgrading things is not an option, it must be = pure upgrade. We can do it like this:

1) Firstly, we observe that MITM only matters when we=92re = trying to count pending transaction announcements, but most of the load = SPV wallets impose on the network is chain filtering. So it=92s OK to = download the chain from any arbitrary clearnet IP via Tor because we=92re = checking Merkle branches.  This ensures we won=92t put excessive = load on hidden service nodes.

2) Secondly, we = bump the protocol version, add a service flag and introduce a new P2P = protocol command =93tor?=94. If a client sends a tor? message to a node = that has the new service flag set, it will respond with a new =93tor=94 = message that contains a regular addr packet, with a single address, the = IPv6-ified version of its hidden service name.

3) SPV wallets that want to get a good mix of nodes for = measuring pending transactions identify nodes on the clearnet via their = addr announcements+service flag, in the normal way. They select some of = these nodes using the standard clearnet anti-sybil heuristics and = connect without using Tor. They proceed to query them for = their hidden service key. After they=92ve done that, they record the = public IP->hidden service mapping and can go ahead and connect back = to them at any later time via Tor itself.

This would seem to be pointless - did we not just go ahead and = bypass Tor entirely, thus making neither node hidden? Is it not a dead = cert that the next connection the node gets via Tor is likely the same = computer? Yes, but it only matters the first time. As long as those = nodes are somewhat stable the mapping will be recorded on disk and the = next time the wallet starts, it=92ll skip straight to using = Tor.

The goal of all that is that we = get to keep our existing IPv4 based anti-sybil heuristics, so we can=92t = possibly make anything worse, only better. Plus, we=92ve now set things = up so in future if/when we come up with a better anti-sybil system based = on anonymous identities or other fancy crypto, we can take out the = =93connect via clearnet=94 step and go straight to using hidden services = with only a very small set of code changes and no new protocol = work.

I like this idea for several = reasons:

  1. It feels implementable to me in about a couple of weeks = wall-time. The tasks are small - the new tor? p2p message is super easy = to implement because a node already knows if it=92s a hidden service or = not. On the bitcoinj side, it=92d take a bit of work to implement the = extra storage of IPv4->onion mappings and ensure the right kind of = connection is used at the right time, but it=92s not all that = hard.
  2. We could switch Tor on by default for a lot of = users.
  3. On= the bitcoind side, Tor runs as a separate process and because it = initiates connections to bitcoind, it can be easily sandboxed, e.g. ran = as a different UNIX user or even run inside a chroot/ptrace jail. Even = though Tor is likely to contain exploits, we can easily keep them away = from the wallet. So there=92s not much additional surface = area.
  4. Obviously as it=92s pure Java and client only, Orchid is = immune to buffer overflows/double frees and other such security = problems.
  5. It=92s optional for all parties. Wallet clients can try to = fall back to non-Tor usage if their access to Tor seems to be blocked = somehow.
  6. Tor is the gold standard for resisting traffic analysis - we = know thanks to Snowden that it=92s good at this = task.

To launch I=92d = probably have a percentage throttle hosted on some SSLd website, so we = can control the load placed on the existing hidden service = nodes.

Feedback welcome.






= --Apple-Mail=_00AA894D-AF71-4024-B559-552757363EB1-- --Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIZmzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGNjCCBR6g AwIBAgIDBnIfMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDIxMDExNDU0WhcNMTQwNDIyMTMyMjMzWjBVMRkwFwYDVQQNExBraUxnVHZjUWRZY0IySldQ MRgwFgYDVQQDDA9taWtlQHBsYW45OS5uZXQxHjAcBgkqhkiG9w0BCQEWD21pa2VAcGxhbjk5Lm5l dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLeGOyJFqq/jERHs+8X/CwcZ+NRs80U dYZOTblQaE5+mELLNCnL+55EWyfre8zUVHXcRdnaGETCC5S5edkBxjDxbfPD6o8R4zIoZyHpxjFd +j98rCEsHUkvjygw2ALGp5vV3pBaLmYa323J4E+VCV6wfpQsBaQgZe9yLE44hRfJ12ObpwVIJrao To6ehX++Kn/tKMhe4WQuPm4gDHGFQHzisIf9/03Dn9kRIeqhxjfIXT6osiQPhdLi76Ijzi2UabHr jGpivhWQoY+hdLTuPsCKw3Z/Mp2K7nGjPPuHIyRshbPys9Epcx/h81XJGTAFqbswHJwfu6tdV0Gp FOHwzq0CAwEAAaOCAtUwggLRMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUyEcJY3IWy2yXzEK+hzh7tO19psUwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGgYDVR0RBBMwEYEPbWlrZUBwbGFuOTkubmV0MIIBTAYD VR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2Ns aWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs YXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAd9sNcxjNTqAQyyRBCsaZKAQKVlT7zN4wqw8DTfnP4wXh6ycgayxg 5Ga6qy85aitivfMcyJuM7ojAWXBjBAlKIFYL+dlPByWFFVxaAsYD/rhhLP1t+nGHLA06YLtz+pJo icODvOoyxlPTp66qeu/TMT8WTaO5Qpdr0Tn3MLPMwJN7BewLng8zpxoOV/u/xrmpkMV2PwlpTonb L9VNUWYI0VsBG/0MDiLEQw6rg668gMRK06bM8GovzLU7i2z2Q0tz1kKeYKHAluC1N84qrO3V9tkp oNDFPHlGfdmdkJDZeW7gF99+kCQVqr5pIadbp0Tmj7Kttwou1juSa/iaDgoMyDCCBm8wggRXoAMC AQICEADVy4nCkwCb7b0BS9wQlgIwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCQ0gxFTATBgNV BAoTDFN3aXNzU2lnbiBBRzEjMCEGA1UEAxMaU3dpc3NTaWduIFBsYXRpbnVtIENBIC0gRzIwHhcN MTAwMzA4MTQwNTA0WhcNMjUwMzA0MTQwNTA0WjBXMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dp c3NTaWduIEFHMTEwLwYDVQQDEyhTd2lzc1NpZ24gU3Vpc3NlSUQgUGxhdGludW0gQ0EgMjAxMCAt IEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4cSEEXIyNDHcWYj3QrVO/5OBfrIU aK4au+FEcSFe4MvQ9/wV3p9DGSTf8vljcgHNPIYo4iHYh8xJVn7HK7PG6yS+JnoQsl5c8DI7UE5Z W/kjfHj45W+rDmyhntQqG7FjPZQoPWdlC2lGkV2NEtenU+U0jXf2NpQw3LiPtF3CjliXr8BdusJk vUm0ItfaJabF4+ygFa9qAm9YLGYaMNck17CoKsCVtDdaFKjBm3ColZeB5GAEZTwdBwFnHNp9fXvn +QuNwhE5wMZT46pVXNbJlCrnEdblmiWEhei9jB5381hSsKai/zLaldVQ/aSu10WYg5KKkUfSWVVS cT+j6PtM2QIDAQABo4ICQzCCAj8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFOlEhoCS6k5Qd8nnkghC11/AwiVCMB8GA1UdIwQYMBaAFFCvzAeHFUdvOMW0ZdHe larp35zMMIH/BgNVHR8EgfcwgfQwR6BFoEOGQWh0dHA6Ly9jcmwuc3dpc3NzaWduLm5ldC81MEFG Q0MwNzg3MTU0NzZGMzhDNUI0NjVEMURFOTVBQUU5REY5Q0NDMIGooIGloIGihoGfbGRhcDovL2Rp cmVjdG9yeS5zd2lzc3NpZ24ubmV0L0NOPTUwQUZDQzA3ODcxNTQ3NkYzOEM1QjQ2NUQxREU5NUFB RTlERjlDQ0MlMkNPPVN3aXNzU2lnbiUyQ0M9Q0g/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MGEGA1UdIARaMFgwVgYEVR0gADBO MEwGCCsGAQUFBwIBFkBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1Q bGF0aW51bS1DUC1DUFMtUjMucGRmMHQGCCsGAQUFBwEBBGgwZjBkBggrBgEFBQcwAoZYaHR0cDov L3N3aXNzc2lnbi5uZXQvY2dpLWJpbi9hdXRob3JpdHkvZG93bmxvYWQvNTBBRkNDMDc4NzE1NDc2 RjM4QzVCNDY1RDFERTk1QUFFOURGOUNDQzANBgkqhkiG9w0BAQUFAAOCAgEAOoY+H9Ann9SpqVsH Be34r3tt2coVn5386F0UiH1IhaWNMVZoq0/sKjXuWp+kZrkNAqWwhvk4qghllxtngI7DSG4+1/9S Gnpe8DTvngRHesAzVkbHfCoNqlKGBnjCp6i+cdmzOb3opj0MCd5kQkPksw3YTkBXJDiNaU43YRRX b1uEAgQbizKkBgxZGpjDa4FSs5ry+Yq2rXeaUlPWmCR9wZS5kZ1anyfwyRSmFQK/bPMikCw9ySe2 8Dtz9nMNwZmHNGvhGYUF+F0QHMb+sdbGx6TD465fqdYe5M7/YpElRvS6jKOPScqUZoq0xxrBakc4 XPQgNOCrCRu0PKgROWeUGv3zZw8uY5Xy5DJoe7F7anxEJgTw9A41S0WDh75Iwjr9l91S9IzeiGR3 g6S6hrek98PWjdHmAfIo9FHGCSXbJFfa958h82QKnydUy79enXwRcPbvlw1FoTkBWgc0uceIx3jV MlU7NyE+0PCiMIWM/YBbn0B0KmTYb2hdde8YDGp2M+qbW2wQv1gjC9vtm0Ens1bemN3GgeWQxQXM AYXDJWb+dFy1sOIwvhzp31ei06x4C3EuiQXINzkQdgOL/7b5e5r23M4xWdISv9IEHwPc4IuXJ2NB rB8zk9RmZRcQOjeHdwDM7n+i3FlPjL2/StV28qIuPiwzYjQhzQOBQM+7xd4wggayMIIFmqADAgEC Ag8A3Hz8Etjr03yOomWvEiEwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzExMC8GA1UEAxMoU3dpc3NTaWduIFN1aXNzZUlEIFBsYXRpbnVtIENBIDIw MTAgLSBHMjAeFw0xMzExMjExNDI5NDhaFw0xNDExMjExNDI5NDhaMGcxJzAlBgNVBAMTHk1pY2hh ZWwgSGVhcm4gKEF1dGhlbnRpY2F0aW9uKTEeMBwGCSqGSIb3DQEJARYPbWlrZUBwbGFuOTkubmV0 MRwwGgYDVQQFExMxMzAwLTgwMTUtMTU4Ni05MTE4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAhgAkK5PH/nRIcQcBZamR4P7jkS96g+ud/Tqi32bElgSzuuW6aWzOE0n/XR5HWf40mDx1 dRj0WM3dt/7Cl1KomoShfIsNxHxcG420vpeoQNQd8r8TokojCX6Y5l+TlAvSPdGhIyEOXG3puryO 4XBZNYHVkZ9fwhC7bau1sbn7mcU2qba/TwkRDGIFSiCml6z8rBMiJ/cSII2QcNgS+ziv82Uhz4i4 GVNPOmegboHkE8qT+gouEeVWMLivXDbAwQF1fBaE75z/Wr+w0K6YJtS7oAbgwIEJpe8/1/OS8HI8 46+02eMxThD+vqwnxcQo+EpicvoqmOsjnLErQG1cTA556QIDAQABo4IDaTCCA2UwTwYDVR0RBEgw RoEPbWlrZUBwbGFuOTkubmV0oDMGCisGAQQBgjcUAgOgJQwjMTMwMC04MDE1LTE1ODYtOTExOEB1 cG4uc3Vpc3NlaWQuY2gwDgYDVR0PAQH/BAQDAgeAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEF BQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUp8JGBqJ9qpKjNlth17DhQ+pIAG8wHwYDVR0jBBgw FoAU6USGgJLqTlB3yeeSCELXX8DCJUIwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5z d2lzc3NpZ24ubmV0L0U5NDQ4NjgwOTJFQTRFNTA3N0M5RTc5MjA4NDJENzVGQzBDMjI1NDIwgaig gaWggaKGgZ9sZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RTk0NDg2ODA5MkVBNEU1 MDc3QzlFNzkyMDg0MkQ3NUZDMEMyMjU0MiUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbYG A1UdIASBrjCBqzCBmwYIYIV0BRoBAQIwgY4wTAYIKwYBBQUHAgEWQGh0dHA6Ly9yZXBvc2l0b3J5 LnN3aXNzc2lnbi5jb20vU3dpc3NTaWduLVBsYXRpbnVtLUNQLUNQUy1SMy5wZGYwPgYIKwYBBQUH AgIwMhowU3Vpc3NlSUQgaWRlbnRpdHkgYW5kIGF1dGhlbnRpY2F0aW9uIGNlcnRpZmljYXRlMAsG CWCFdAFZAQEBATCB2wYIKwYBBQUHAQEEgc4wgcswZAYIKwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3Np Z24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkL0U5NDQ4NjgwOTJFQTRFNTA3N0M5RTc5 MjA4NDJENzVGQzBDMjI1NDIwYwYIKwYBBQUHMAGGV2h0dHA6Ly9wbGF0aW51bS1zdWlzc2VpZC1n Mi5vY3NwLnN3aXNzc2lnbi5uZXQvRTk0NDg2ODA5MkVBNEU1MDc3QzlFNzkyMDg0MkQ3NUZDMEMy MjU0MjANBgkqhkiG9w0BAQUFAAOCAQEAQENx9hsahnGo3u/8ksy53OxZkaSISe6e4XT1i/o0qZ6D Kd9noZ2LvbclyyNo3Q9W4TU1pP41yf4JcL25sx1z7U/e9Ze7vTZN/GZ+gv20gaCqm/cQWF19PjzT PqYXvJjGK6euiQzACN/IEjxeuzaiml02jpFnH1VrNvgfib/WQCL9y1dK6aLx9noP3CXCnd0ZWhYI dh1e4NZXetRFKII1z/iAlevHmEdLAv0XgKFA6RnBdxCFdw6E7cz2TUS3m59IkrE3z/3swGV+lg7Q 60ZNMAeskg1+zhNpaY9FyBdRDXk2K43ItgE5Mr8+LCdGwoIofXubME12En6DuOnQ38mqGzGCA0Qw ggNAAgEBMGowVzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzExMC8GA1UEAxMo U3dpc3NTaWduIFN1aXNzZUlEIFBsYXRpbnVtIENBIDIwMTAgLSBHMgIPANx8/BLY69N8jqJlrxIh MAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE0MDExNTIyNTEyMlowIwYJKoZIhvcNAQkEMRYEFHLpdx7yG1lUOrBhxFwwoM+5lk6xMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBnIfMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGch8wDQYJKoZIhvcN AQEBBQAEggEAgaw/6YEr2aQ7xYd0rYcLPRFMCfYUUD+CvSG2H4TvXRHsgWKqcb9WHcfOucVRQdng 9wc+Z519DtapjFSfGu7XcfCqPTfIt9mdRL2jHTRhMZV/j5tXscHgWD2h3XybnlDevzgg69zeZrs/ 9ev61XDr4N/ljbHx1mpz6QOkMFge+3QJE2Ew+vJLwKOmmZpBvPi6VR3JQ/A7OeyWCxCpX0l/AiiT 9qQl/5UXXqd7/VxYn7zV+JMEMbctj1pHpAJE0/CVmfVm/PNiuZI3t9J5BWi0+s/i2PTcrTeSt2P0 S4jwLfVap7YOJX7R1YQs0Y+zaZqCF4KV/88sMtnddchptIsa6wAAAAAAAA== --Apple-Mail=_01340681-1782-4989-AAD7-C6ECAB5C893C--