Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499B53A0EF6 for ; Wed, 29 Jul 2020 13:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2sw7W-yxjN0 for ; Wed, 29 Jul 2020 13:48:47 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047703A0EF4 for ; Wed, 29 Jul 2020 13:48:46 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id x5so3890027wmi.2 for ; Wed, 29 Jul 2020 13:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=efDGx4OKUD6YuArYBssgpJxnig2zGvHRH3blQtqQvv+2RkroVJI20pJRcsMFeLZcTA regPl2wXZjIxzcjRW5DuG4MnvBthBsowFUArKbYGg4IN2RKA8wIH3avy/XjlodicA9x7 jOwUMzRv7j1G9MrToVcbA/rNxajJT4JP/mf68nM60fDH1rFzVZVs0MbXv82c6iyC27X1 ZO6+pGYVV8AE8ILQhCb755RoQFG7xI/fwfPIMGxXSdUis82+2skIC135/DGgvwW7CQew PPQweLaJvARMGevqOcMayV/gquoKUuamBEGjgnVpLmIVzFxXwkJgeChkdcJS1bgKLSrB CIEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=pMFfb4cWql5ZgpHP4AZXPwfE6dBYu4a+IjEXy/hU4ZshiE/luXXo3Umpaq15v1ZZE4 nfZu4q7Ub0GH8Va3QLDCzSo0MJZABEivINT++VDkXGM85BDmPg9/Tv23TJcSLpnky1El z0t7+YURSfxqyNbVTHB0hN01uSR4yrI2EEf+Hte1w4C7t0xgaFx5QlaLJ6FRElSZcSvP M0t5A1ZGYwM23wyNJZR643vUmq6wTtWWh8Y2Z+XcTH3rY2zswborEOyVNsCk1LMq/sOe 8R9FwVR3RJt+g2yL/4i58mwnCX72ql4drD2ndqfvrYkfFRPOhgNLETInQBZbNI9jNsYl eJig== X-Gm-Message-State: AOAM530um5lPi49oekk1JumoGWbFC+3L3ysufK33eWG7tA+LVz5c/TOz gh7dRWbAczLtJVtMtz/cnNH/i31/6uGufkpaHPzHyHukW4k= X-Google-Smtp-Source: ABdhPJwJy+hKA8gdW946ft46MRwQtnEK42QssB4DGLaWjE2u4wxCfD2BRE3lDE13atEh9oDrvRc1FX+aK8YSN7EyVOI= X-Received: by 2002:a1c:4183:: with SMTP id o125mr10216871wma.101.1596055725154; Wed, 29 Jul 2020 13:48:45 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> From: Ben Schwartz Date: Wed, 29 Jul 2020 16:48:33 -0400 Message-ID: To: Christian Huitema Cc: Yiannis Yiakoumis , network-tokens@ietf.org, "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000092a11305ab9aae93" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 20:48:52 -0000 --00000000000092a11305ab9aae93 Content-Type: multipart/alternative; boundary="0000000000008aa97e05ab9aae36" --0000000000008aa97e05ab9aae36 Content-Type: text/plain; charset="UTF-8" This proposal is highly ossifying. Application protocols that are included in this scheme become very difficult to update. For example, in the case of zero-rating, this proposal would only be able to zero-rate application protocols that are understood by the network's token-parsing appliance. This seems likely to have serious negative consequences for protocol innovation, as these applications would no longer be able to implement novel protocols without losing whatever advantage the network token offers. For TLS, this proposal would ossify the extension format, which could no longer evolve in future TLS versions without risking loss of network services. The proposal also violates the TLS Protocol Invariants, by attempting to process the ServerHello after forwarding an arbitrary ClientHello. It would also fail for QUIC, as previously noted, due to QUIC's mobility support, which is important for performance on mobile devices. Additionally, storing this information in the TLS handshake causes an unnecessary privacy loss: it forces the token to be visible across the whole internet, even though it is only relevant on the near-client network segment. Even if the token is entirely opaque, a pervasive surveillance adversary could distinguish between connections with and without tokens, likely differentiating certain applications from others. I recommend that the authors focus on the draft's proposal to use an IPv6 extension header, and remove the other proposed encapsulations. Also, please remove the specific extension number from Section 7.1 unless and until IANA has allocated a number. For testing, you should use a value from the Private Use range, 65282-65535. On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema wrote: > > On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: > > > > > On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema > wrote: > >> On 6/25/2020 11:11 PM, Melinda Shore wrote: >> >> On 6/25/20 3:29 PM, Erik Nygren wrote: >> >> One quick comment is that binding tokens to IP addresses is strongly >> counter-recommended. >> It doesn't survive NATs or proxies, mobility, and it is especially >> problematic in IPv6+IPv4 dual-stack environments. >> >> There's been a bunch of past work done developing similar sorts of >> protocols, and for what it's worth I wrote up a mechanism for using address >> tags and address rewrites, but unfortunately Cisco decided to patent it. >> Anyway, there are ways of dealing with this problem that don't require >> binding the address to the token ("all technical problems can be solved by >> introducing a layer of indirection"). >> >> There is also an interesting privacy issue. The token is meant to let a >> provider identify some properties of the connection. I suppose there are >> ways to do that without having it become a unique identifier that can be >> tracked by, well, pretty much everybody. But you have better spell out >> these ways. >> > > You are right that for the duration of a token, one could use it to > identify an endpoint (either application or most likely a combination of > user/application). Tokens expire and intermediary nodes cannot correlate > tokens with each other as they are encrypted. So tracking cannot happen > across different tokens (of the same user), or between token-enabled and > non-token-enabled traffic. I guess similar type of tracking happens when > users are not behind a NAT and their IP address can be used to track them. > Would it make sense to have the user add a random value to a token, and > then encrypt it with the network's public key, so that each token becomes > unique and cannot be tracked. Would that address the privacy concerns > better? > > That would certainly be better. The basic rule is that any such identifier > should be used only once. Pretty much the same issue as the session resume > tickets. > > > Then, there are potential interactions with ESNI/ECH. The whole point of >> ECH is to keep private extensions private. The token extension would need >> to be placed in the outer envelope, which is public but does not expose >> seemingly important information like the SNI or the ALPN. >> > > Ah, I was not aware that ESNI can now include all CH extensions - thanks > for the pointer. Yes, the token would have to stay on the outer envelope so > the network can process it. The main idea is you can encrypt everything > that is client-server specific, and just keep a token to explicitly > exchange information with trusted networks. > > There are also implications for QUIC, in which the TLS data is part of an >> encrypted payload. The encryption key of the TLS carrying initial packets >> is not secret in V1, but it might well become so in a future version. >> > > Haven't looked into QUIC yet, but is on the list of things to do. If > anyone is interested to help us explore this, please let me know. > > You may want to have that discussion in the QUIC WG. If you are building > some kind of QoS service, you probably want it to work with QUIC too. > > -- Christian Huitema > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008aa97e05ab9aae36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal is highly ossifying.=C2=A0 Application proto= cols that are included in this scheme become very difficult to update.=C2= =A0 For example, in the case of zero-rating, this proposal would only be ab= le to zero-rate application protocols that are understood by the network= 9;s token-parsing appliance.=C2=A0 This seems likely to have serious negati= ve consequences for protocol innovation, as these applications would no lon= ger be able to implement novel protocols without losing whatever advantage = the network token offers.=C2=A0 For TLS, this proposal would ossify the ext= ension format, which could no longer evolve in future TLS versions without = risking loss of network services.=C2=A0 The proposal also violates the TLS = Protocol Invariants, by attempting to process the ServerHello after forward= ing an arbitrary ClientHello.=C2=A0 It would also fail for QUIC, as previou= sly noted, due to QUIC's mobility support, which is important for perfo= rmance on mobile devices.

Additionally, storing this inf= ormation in the TLS handshake causes an unnecessary privacy loss: it forces= the token to be visible across the whole internet, even though it is only = relevant on the near-client network segment.=C2=A0 Even if the token is ent= irely opaque, a pervasive surveillance adversary could distinguish between = connections with and without tokens, likely differentiating certain applica= tions from others.

I recommend that the autho= rs focus on the draft's proposal to use an IPv6 extension header, and r= emove the other proposed encapsulations.=C2=A0 Also, please remove the spec= ific extension number from Section 7.1 unless and until IANA has allocated = a number.=C2=A0 For testing, you should use a value from the Private Use ra= nge,=C2=A065282= -65535.

On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema= <huitema@huitema.net> wro= te:
=20 =20 =20


On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
=20
3D""



On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM, Erik Nygren wrote:

One quick comment is that binding tokens to IP addresses is strongly counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the duration of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that any such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ESNI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.


Haven't looked into QUIC yet, but is on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If you are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008aa97e05ab9aae36-- --00000000000092a11305ab9aae93 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCD11GBcrH3+fQAhgjTrSUaPZKP8MwXxmfKrLliTtguFazAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MjkyMDQ4NDVaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAIHwr44FHQaQ19mqG96+z2MZ65PfI5J4S/ylYWuEH2cROjayIg5cVIUmQl9qZGyD7SEtbsyap mNc2+HadDsTJEuPxi6/b92An6Njp+UlomcgAITts8F727dG3/6+5vJzolWCY/R3eWJQUYaDRv4r5 G7AO2OTcKH3hgr660Hb3z/bDKG9AtcKQ4O++4REnFdfXZwgdPuVB70wrecOI2KE2shgg5Yhc2cl4 xVJHQqqGjMbK8+mxgLRezxPLfQRM/S1SylKDSiVcbDmYJVAnRc7vCOW8bCqHTi7n/12rLU7snl7J aemvYj6VTGgtjH7ZWsfqlcbgxQbRB1rCK5JklMbGQQ== --00000000000092a11305ab9aae93--