<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-richsalz-httpbis-https-downgrade-02" category="bcp">

  <front>
    <title abbrev="TLS-Downgrade">Best practices for TLS Downgrade</title>

    <author initials="B." surname="Sniffen" fullname="Brian Sniffen">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>145 Broadway</street>
          <city>Cambridge</city>
          <code>02139</code>
          <country>US</country>
        </postal>
        <email>bsniffen@akamai.com</email>
      </address>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>145 Broadway</street>
          <city>Cambridge</city>
          <code>02139</code>
          <country>US</country>
        </postal>
        <email>mbishop@akamai.com</email>
      </address>
    </author>
    <author initials="E." surname="Nygren" fullname="Erik Nygren">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>145 Broadway</street>
          <city>Cambridge</city>
          <code>02139</code>
          <country>US</country>
        </postal>
        <email>nygren@akamai.com</email>
      </address>
    </author>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>145 Broadway</street>
          <city>Cambridge</city>
          <code>02139</code>
          <country>US</country>
        </postal>
        <email>rsalz@akamai.com</email>
      </address>
    </author>

    <date year="2019" month="September" day="19"/>

    
    <workgroup>HTTPWG</workgroup>
    

    <abstract>


<t>Content providers delivering content via CDNs will sometimes deliver content
over HTTPS (or both HTTPS and HTTP) but configure the CDN to pull from the
origin over cleartext and unauthenticated HTTP.  From the perspective of a
client, it appears that their requests and associated responses are delivered
over HTTPS, while in reality their requests are being sent across the network
in-the-clear and responses are delivered unauthenticated.  This exposes user
request data to pervasive monitoring <xref target="RFC7258"/>; it also means response data
may be tampered with by active adversaries.  Terminating TLS
connections on a load balancer and contacting a backend over cleartext has
long been common within data centers, but doing this TLS termination and
downgrade to HTTP at a CDN introduces additional risk when the unprotected
traffic is sent over the general Internet, sometimes across national
boundaries.</t>

<t>While it would be nice to say “never do this,” customer demand, content
provider use-cases, and market forces today make it impossible for CDNs to not
support downgrade.  However, following a set of best practices can provide
visibility into when this is happening and can reduce some of the risks.</t>



    </abstract>


  </front>

  <middle>


<section anchor="background-and-motivation" title="Background and Motivation">

<t>Browsers are helping drive a push to universal HTTPS through a variety of
mechanisms, including:</t>

<t><list style="symbols">
  <t>Show HTTP as “not secure”</t>
  <t>Showing mixed-content warnings when images or advertisements are HTTP on an
HTTPS base page</t>
  <t>Making “powerful” new web features available only for HTTPS</t>
</list></t>

<t>On mobile, app stores sometimes require HTTPS for acceptance.</t>

<t>These factors have pushed many content providers to quickly enable HTTPS, even
when their origin infrastructure is not ready or not perceived as being ready.
Being able to use a CDN to convert HTTPS to HTTP has been looked at as a fast
path for getting onto HTTPS quickly.  Doing this has value in protecting
requests and responses over the last mile, but admittedly does not address or
worsens some other types of attacks (such as pervasive monitoring, or
corruption and manipulation of content crossing national boundaries).</t>

<t>Delivering content over HTTPS but fetching it insecurely over HTTP is done for
a variety of reasons, some of which have historic motivations with better
alternatives today, but where content providers are resistant to change. This
includes:</t>

<t><list style="symbols">
  <t>Lack of HTTPS support in origin infrastructure, such as due to using load
balancing hardware that does not support HTTPS, has bad performance
characteristics with HTTPS, or which only supports SSLv3.</t>
  <t>A perception that HTTPS is more expensive to deliver.  In some cases content
providers may have origin infrastructure using old hardware where this is a
real challenge and they lack the budget to upgrade to servers or load
balancers that can handle HTTPS well.</t>
  <t>A perception that using HTTPS introduces performance issues, such as due to
the additional round trips required to establish connections.  This can be a
real issue for origins that lack persistent connection or session resumption
support.</t>
  <t>Challenges in managing origin certificates, or a perception that it is hard
to get TLS certificates.  Automation with providers such as LetsEncrypt help
here, but some content provider origins may be using software or hardware
elements that don’t yet integrate well with Auto-DV or may have organizational
policies against using DV certificates.</t>
  <t>Delivering the same library of content to end-users over both HTTP and
HTTPS, but wanting the CDN to cache any given object only once.  This can be
better addressed by always fetching content via HTTPS and storing in a cache
accessible for both HTTP and HTTPS requests, but this faces challenges for
transitioning from an entirely HTTP-fetched-and-served content library to one
that is served over a mixture of HTTP and HTTPS.</t>
  <t>A perception that there is no risk to their users or brand reputation,
sometimes due to thinking of pervasive monitoring and content manipulation as
esoteric threats that don’t apply in their case.  For example, content
providers delivering on-demand streaming movies may not see a threat from
using HTTP and may view DRM as addressing most of their immediate concerns.</t>
</list></t>

<t>There is also a closely-related issue where content delivered over HTTPS has
been pushed to origin infrastructure over an insecure protocol.  For example,
content uploaded to a storage service over an insecure protocol such as FTP, or
live streams pushed from encoders to ingest entry points over an insecure
protocol.  This has the added risk that authenticators may be unprotected
on-the-wire.</t>

</section>
<section anchor="recommended-alternatives" title="Recommended alternatives">

<t>The “right thing” to do is to use modern secure protocols and cryptography for
secrecy and authentication for the request and the response when interacting
with content origin sources: HTTPS for pull-through caches, and protocols such
as SCP or SFTP or FTP-over-TLS or HTTPS POSTs for pushed data.</t>

<t>Origin sites that avoided TLS for fear of a performance hit should collect
data on the actual costs with modern implementations and modern crypto-support
hardware.  These are expected to be under 2% CPU overhead, especially when
persistent connections are enabled.  Auto-DV certificate management can
make origin certificate management straight-forward and automateable.</t>

</section>
<section anchor="potential-risk-mitigations" title="Potential risk mitigations">

<t>An intermediate cache can take several actions to reduce the risk of
unpleasant consequences from using TLS downgrade – though these practices do
not eliminate that risk.  They take two general strategies:</t>

<t><list style="numbers">
  <t>Informing the endpoints that this downgrade is in place.  End points have
more information about the details of the connection, and can expose details
to human controllers. For example, returning a response header such
as <spanx style="verb">Protocol-To-Origin: cleartext</spanx> and preventing customers from removing it.
Clients may then choose some manner in which to expose this to end-users.
(Some other proprietary implementations of this response header have included
<spanx style="verb">X-Forward-Proto: http</spanx> and <spanx style="verb">CDN-Origin-Protocol: http</spanx>.)</t>
  <t>Restricting the sort of data in transit when downgrading from HTTPS to
cleartext HTTP. Examples of this include:  <list style="symbols">
      <t>Limiting to GET methods.  This prevents unauthenticated writes to the origin.</t>
      <t>Refusing to downgrade requests for <spanx style="verb">/</spanx> , <spanx style="verb">/index/</spanx>, or <spanx style="verb">/index.html</spanx>.
This prevents accidental delivery of the entire site.  The goal is to
rapidly detect a misconfiguration with too much downgrading by breaking
the site.</t>
      <t>Limiting the content types or file extensions (e.g., to streaming media or
other static media assets).</t>
      <t>Stripping outgoing request headers containing potential identifiers
(Cookie, etc)</t>
      <t>Stripping query strings</t>
    </list></t>
</list></t>

<t>In practice, stripping query strings breaks an enormous amount of Web traffic:
searches, beacons, and the selection apparatus of streaming media clients.
Mechanisms that rely on lists of what is allowed (file extensions) or what is
banned (such as “Cookie” headers) rely on an implausibly detailed and
up-to-date models of Web use.</t>

<t>Other headers that may wish to be stripped from outgoing requests include
<spanx style="verb">X-Forwarded-For</spanx>, <spanx style="verb">Origin</spanx>, <spanx style="verb">Referer</spanx>, <spanx style="verb">Cookie</spanx>, <spanx style="verb">Cookie2</spanx>, and those starting
with <spanx style="verb">Sec-</spanx> or <spanx style="verb">Proxy-</spanx>.</t>

</section>
<section anchor="recommendations" title="Recommendations">

<t>It is recommended that CDNs do at least the following as default behaviors as part of TLS downgrade:</t>

<t><list style="symbols">
  <t>Providing and encouraging better alternatives (such as always fetching securely over HTTPS but making static objects available in a shared cache that can also be accessed via HTTP requests).</t>
  <t>Returning a <spanx style="verb">Protocol-To-Origin: cleartext</spanx> response header (which may be a comma-separated list of protocols when multiple hops are involved).</t>
  <t>Limiting downgrade requests to GET.</t>
  <t>Refusing requests for <spanx style="verb">/</spanx> , <spanx style="verb">/index/</spanx>,or <spanx style="verb">/index.html</spanx>.</t>
  <t>Strip at least some headers that may include personal identifiers or sensitive information.</t>
</list></t>

</section>
<section anchor="alternative-approaches" title="Alternative approaches">

<t>Some other approaches may also help address the risks:</t>

<t><list style="symbols">
  <t>Use a VPN or IPSEC or other secure channel between the CDN and the origin.</t>
  <t>Validate asymmetric signatures of content at the CDN before serving, such as
for software downloads. This helps with integrity, but still exposes
confidentiality risks.</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<section anchor="risks-of-doing-downgrade" title="Risks of doing downgrade">

<t>Downgrades allow protection of last-mile connections to end-users, but they make
it easier for adversaries who control the network between CDN caches and origin
(such as at national boundaries) to poison caches or perform surveillance (as
correlation attacks are possible, even if ostensible PII information is stripped
at the CDN.)</t>

</section>
<section anchor="control-of-the-network-between-the-cache-and-the-origin" title="Control of the network between the cache and the origin">

<t>ISPs on the HTTP path, including nation states at their borders, can surveil
traffic.  They can expect to get end-user IP information from
<spanx style="verb">X-Forwarded-For</spanx> or similar. In some circumstances, they can learn more from
correlated timing and sizes.  This is principally a risk to <spanx style="emph">secrecy</spanx>.</t>

<t>Active adversaries can also corrupt or modify content.</t>

<t>For executable content (such as software downloads or javascript) this can be
used to compromise clients or web pages, especially if no end-to-end secure
integrity validation is performed.  Even when software downloads have signature
validation performed, this can provide a potential exposure for downgrade
attacks, depending on client-side implementations.</t>

<t>For site and media content, modification can be used to make content appear as
authoritative to a user (delivered via HTTPS from a “trusted site”) while
actually containing selective modifications of the attackers choice, such as for
the financial or political benefit of the attacker.</t>

</section>
<section anchor="confused-deputy-issues-at-the-browser-or-origin" title="Confused-deputy issues at the browser or origin">

<t>HTTP clients make different decisions based on whether they are using HTTPS or
HTTP – for example, they send Secure cookies (cite), they enable certain Web
features (high-resolution location, Service Workers).   This is principally a
risk to <spanx style="emph">authentication</spanx>.</t>

<t>This attack is only available with downgrade.  A related attack is available in
the case of HTTP <spanx style="emph">upgrade</spanx>, in which a server makes a similar decision based on
seeing HTTPS on its end of the connection.  In cases where HTTP requests are
upgraded to HTTPS, CDN or proxy operators need to work with origin operators to
control this complexity and prevent the complementary attack, such as by only
performing upgrades for cache-able, static, and idempotent content.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>




    </references>



<section anchor="acknowledgements" title="Acknowledgements">

<t>Thank you to Suneeth Jayan and others at Akamai who have helped develop best
practices. Future versions of this draft hope to also incorporate best practices
developed elsewhere.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIALgthF0AA8VaXW/cSHZ9b6D/Q0WDIHLQ1Hq8WSSrvMSW7V0H9oxgaWYC
BIFVTVZ314rN4rJItXsW+99zzr1VJFuSk8cxZuzuJll1P8899xaLolguet/X
7tKcvXGxN21ny96XLppN6MztxxvzNhyabWcrd7Zc2PW6cw+X/L0Yf18uqlA2
do81qs5u+qLz5S7a+tdi1/ft2kf5NxZVfqB4+XK5KG3vtqE7Xpp12S4Xh9Dd
b7swtJfmz7e317/8abnwbXdp+m6I/auXL//48tVysVzE3jbVF1uHBrsdXVwu
Wn9p/rsP5crE0PWd20R8Ou754X/4hB36XegulwsDVQ3++CZemjcX5qbxm41r
9EcV/03nbXN6IXTbS/P63u6tN7eu3DWhDlvPjXk1YkPXX5rv/+UPeDjY6mCP
eqX0PVS7svt156utSz+GCru8fPX97/+Yfxianjb46UZ/cNinhkmiyvAfVna+
KMP+kQKfLswbH3ehncv/yd+7k59/G+n3axHh28K/uzA/HLfdqfHfdf7+5Off
RvhGJPi27J8ROYjtueSfEe+zH38buTtm3InYy0VRFMausSNymt+vQtO7hkke
HnzlumgqV/sH1/lmi4X14oO35urtD9EcfF0jqfau93s33prvWy4CvzFZb8w5
sGId+l36ihyVTy/Meuj5wMZvh86Zfue4tOmDaQcsvunCnj9irc5vfWNkybJ2
tuvd117WGRpmMDb0RAxd98KY9+lR00KN1gGzHpwJG2OBLLXH7SvjsUDbYq2I
G23Pu31nOvfXAUAXZXEbYyi9rNu52IYmQlELSZOyrpqruTKHna8d4gB32xru
erImHl07WjPSlLbsQowiZuN6QhxQrSnwvRAlRYZvbPxYceh8u/PRuK9t4M1D
dN1ykXY2le2tmNV1DzbSFvvQ+D6IZ//2t3/4/P7qX1/94d/+/vd/F7PUMZi9
s00cd5cVlou9PUIB09t9K0IcPJy6PhqrBrYVZIu2QzRTHtftfWN77oGKAMuH
pqErsKAJjbGmRnybta1tUzrVltHDxfCIxZXy3uHHR27fWeQKIH4LUVyDR/ZQ
RkSB5UXTEmaBICuJrypwtZ7GYb3qs1SUoKlYnVLdoYHoSINgkBiHJ/suVAPL
na0qz2dsbTof7+FqbE3PDQ3SpYdaDAak0mbjS4O9xMMiOe/ausZ1ePYDBYOz
V7PMSWGgMtl6uVgjhyu1ItPyF42q3hzCUFe0f4MKTGkj3HHWOG5SBVFxdWZK
VESsjZ+Q+k21mjIy5zWDoygtwmQlRt/b7t71rOjUtA8Vlt3be9nT7xFP0a8h
ASu+ZD52bgLWi0Pboqia0YJw+p/DgfKscHddh4M6MmJ1JN/6lEGUKKZJpOXi
wWMTL0kDq4dsXxgS/+2YqI2sxRixTDC6RYzIlWliukUNRlzb+6qqHb99Z94g
jkgemNH4/1NAsIqxeRkge4jEOqbXztUtt6k6CWfAUNxR3aHxEtl1QrB+h+W2
O9zxQD9B6LBBdgDNbePjHnb1TVkPFda6FInMzS4cUnRF+Cz0MEoJ0DubLnPj
vf/qqiJj7cF21DqqNfzebmE2eEHyrPfR7XGXSi5LS0gT9lXKNVxsWrt1uscn
e88tzlq4qNsM9RlQ52AObm02zvaQBSs9oFhYOjs09VE8LktxgR8bgAZc5FbE
TRSqwCemMCbW+CTJjTxqy9K1PZNb3HK7c5BnA/eHjj6FhWlfxwBsjmOBmaoP
DI8ly3tI4hqRKuEsIgxq5hQEwqb64JtNZ1HPhpLqMHJoaIBxdaTZ+AW4VTo4
k+CesFiuQ8I38k32ocujSyiAL5CNFs/eTzixkyUgRB3CPVfsuaiFipHZZoGN
NMPW9QJooUkP3mS1kC9vJ3Ticg+2HqSCJFDBxRHF46N6MIJLjf0QOfQMAc9W
e98DjmC2Kji1AeALDzJ4hEsDnGJKHiyAVY4tF0R97AG/99GcxwGkBQI9VzFW
skwZum5oM47Shx5VW4EVK2V3CrhRx4xvZoK3FxIXb5+SjBl3oEYb15c7Xicg
NZo40G68i56uwPlpblD6WVLSuRHmWo1QgRoNzST6YHQqVEK1jAgxlTS4jPXT
1oRry+KWgFFNjNBDfD2NWGYi7OzZh/QSOACELXCRtZnFnaDgomDCP5uPMDVF
UkUzmpLnPBfOUCH5pBpShNIkrKEoGVJE+X1nO3BGYVO2nwIgr54ySEIXxRfu
hc32zFF4FM8iO+GKCIROpkgPII7VcgIMabVobm4+Pvz+QtV5rcmlISG7q2Jw
zh5YQWqCsGMoQfhEZJABHxr1jRSkp8UKD6Mcib+ez3I1Q0BlHFVX9+TqYZlB
iDuoV9cO7pB4RdwfkTnwAFNoPYBSi8eGdiQDKAtEfeo+t7LLjJGFCP6tMjAB
S+v6m8ZQOZNJJmIx8wCEjQOL8qmjQSt27oSASCnrO9+OqFtRXmAE0AvNlZkx
rUwMKSyoQzaGbCXwpFZNKolByJkRApK940K0AhwU+REhPuxbraApFJLaV9nG
kXEMrexWvKOeK1m1NkJYo4SUfWIlZngUT0LtQOwU1jZ/Ehq9HkBxFGokSKdg
yab76Pr4rim7Y9tLVV8uGBOavRpuj5J3tEPiuOquGDa9hBSEzeG1XLg6Vd6U
Y80/9ebomLq9Q/T0TiJBRaOoxdufucAskLdAy19HwteG2pee9XdrIUKOFTx1
oreaeAaXjIuIHtPUft3Z7jjHXcZDUxWDcBtByrEDU96bElvgDGiV18sVz5YM
OtTlLXaD99d/QRxo9gdW9JOwQmoIYuY6g3hkV1CjeY0Tes9byKkTjKkN8ewI
ZFvgLpjDjHWeSJ4ezUVRNZBcB7UggkwhKOUAnByoQ1NzF+kpITMbJykiXK0Q
EUG8sHwhWV+NwmbTwiaoMMxF2yu/l9vEspa8TcAoofkk5zfhoBeMEoqiHUUf
EplJLoPanRb8duglVFbItqnf1iLApkdoHXZ+trvLXRV1OanR7KJcDIT7koQW
HPAkoEHyapLxJBXhmY015HJf0f+RbTwD1rOJQWgKbUFkqGH3wm9xn9McUw5M
kqWbi2uWiwkmE604Il7AU99+/iTsSgNM14p9Iv+Qz+/3rmKvTqmQNk3MpFPN
LE0tAqxGe1wfC/he+nrFwdN6PjXZMx4iXaewvURaGRDPFiQNiWZkKsLlQhnq
R+aThlg2HFrWF13TSkKAtEuEsdH75noj2L2/vVZORrmTtWOWUyLeNZwUKaf2
zI2eGYCwbsE/+/hkD3FpFvo2s9NUhzgOkYhlsMymEKGb0HPeFQedaRyQcBfa
kX127NqBT2TNM46VPGbOYNidZHWzPRO6EOjDRMv3VKUxj6yh9FgQPwCE291R
8x+3da486kBnEpYpQGyR1jGNSRIvmKYe2nexZ7eJiwumjzRV/R/DwM75ctb6
cH5V5C5RQC312pO0dB6QDhzq6prZfvP+Vv7FPwXdUbDu5QbMXP94cxvT0uJW
DjrEmj8mIXzvUv7ah+BpWS7AJzacJZHcn5CNHUpt3MlIAfLUjjNAmZ4EHWxA
44GsKbDzELWT3T2jl/UvMWZJU72k1i8SJ0DNTSVTgojdn008kIFBd0qosPq+
+kdzdf2TxOEO/Rh6PI7tPKD8KF5AQD7HSpRya3dYJWJQnNZNZSEiMKsVh1j3
7hlGMr+PM1FGYAFrQf4qBw9Jh+NeKY6vA+XxeSiEvstv1Sq8/jrFzghMUlNZ
MXuKEDkowaM2aQJzpLFGHmfIVAGpVKOJsap3ZKg2cgDDvFa0pKOnMVZRYAEJ
vF5sPk1cKnBJwi7wTWZgqUngVuqho0rWH8I4saIpwGp86lq+vwBhZwxlvoAk
ThiSypr0YlkWLzywBa1kDLxjAujN5EFwBfsCL+ulooTmUGojQLi3vo55ujO5
fDUOgXTWme8Uvrgb4EXJz44x3YEsnlSszgGidZI0ZTkDDiE4JuTddUrS4jYU
ml6X0/zxLuUxhxDCmvLALbmkcyxy0qwiSq5k2qy4SOwBPQkUWjgoZIWRaSHt
rcjZVCcx45zCYanzm6lhB4y07HHJTB7no1jMxyf6CfVMLShQ+e6/ivca3YXo
e2l4Dqfa3YEFJs2LbIx0/eIFw+DVBTAcoeHLkTjyfI17C4aQNijvUgzNETFS
sDxJkUOKabar4/t36q5JlST1pR5pFOajZ6px42D+9O7WgBTtQjX2Osk58cnp
wKFTlBSqlTDgIi/62W00naTe5Agehy9E0rvf3ZkV/vbArK+/u5MeJn272PX7
+i4t9lgO8FkgMjxUZ3JxzIGtRFTgW3PQbIP0Z9k4+INq5mWc41hShW7GfGwy
64L6EMyelGBubfDwNfjAvVQvXU68xf2emnM3saA0E0L54PgZzmHzzvg6dxfb
i5U0yBOvI8QJBdEtNEojQ7JMFy3agl5GPrrpDRtYmbYi5bdBJ3FahzVgdRiA
hoiX2hFpxZDAbNyQdzu/CuHeI71B4188XR+Lwt6M1mYrwPyhGUFxJb8/c59a
LWqvAHwKAz7vebpGz/3i1iYN+y9JMWynJX7tbCnjpkwlQDZT/ww+beGtQaL6
seX0UIpZ/mkcIidwlklXgz6EQSgDLG1ALOfriOnzR/55obMauYkjC0BMNc3z
ztRUZ9nGL8YNrFZ2O7DvOiZUdZU2i0NboLBWUiZR6hWXaQSAk7IQcXh2nEhO
yDt4HaCvXbJzJqSPfT7m+ByY0JHhE9LsTrGIn5CloObyo6oyfXp1l+0uCAtw
nHG2uxtXFneSsEC0r8fi7jEXnQr3BzFwNyOpopAcfoCJck7iOHOlg2fnHOx+
Nnaoe6gLsPXkwxyhWgXGkyqdRoDX0jjlPo0sHRktI5PcUM8nkKMXH3fWT0ei
Ojjd68g/5aH28PMpv/TcESyNDa+wk3GwJf0SB0bSiuN67tpHj71Ive3nWU39
/0rn45p0roUvdQ1WDvMsWnBJFWzKqJfWdqTNUk72MLJHhTC70CoF9M1DqNGQ
Z6FGSHsGybVojNIn1P8/gf4ZnOfDgjFTPEhRf5IDKbBlrCbzuxmC6VRN5hMP
J0xINmB4vp4CgBDSBWkmeG1GB6YLsqP4jlOvce4/HpCluPtJTjd+vv6BAny4
vnl3xQ8JtbWvIgw1rmYgHlw67ORwKCPbWD253s+29oIONh6RMyQGKDHbJp0r
zeZSOvqQldZuQ/4nfS5PFVJ0E8Dpg3H2RheyQY4XqRWFZqkl0Ymb79NcPvZ8
KSGdgXMdqZKVVg6eLU6HhN+ZG+rJH68QkZxeTADwHWCBdwqfCSdhJCcW+UtC
4fG0Ro8+eB5T8DzmpFGZs7k8tHJ60LpcgCchghARenA2naMj3kPms/M3BUa3
0JDaYIpn1CsgiyNU9M+evMjbAMEjIPPTbC21PYQjugcHS0qfeE6P8LDH5cFR
OiOia/LhsJ7JGb8xIUohIrpcf/hwQu45NUtFADx7jANllDD5VVIzMaPHmgo5
SWPJeQgKYt9cx9y4Ckjx9G12CptsIEjoohlf91iHrhJ/EPKS2uMxfu6JUq9B
6pVG0tmRSJ0TDXWE9aSASZYDkGrbXUznHb4rh32U81EI0OedCJaNnpjoctn2
LEN+n2tF9L+6kfAK14SyvpWG2Y4TxS9p+vFFYv71k9c0JqhPx3kypw6V34wH
svKkNlFImF7qRk7mMcqe5ioX+gsqTSzh8f6F8vg8LR6itv+Ae6QO2KzLDEjI
C3gFj63jyRQAsdVoCoGJ8LWQPKkaMYCnp74aYy1Fs8wF3jE6pXQ8I6k0RiNa
LRezZcY1VpMCadjJccpISgVyiJpM3xlWpFxZgRm0kFnHoknXgqDzuHsbrU2C
rqMVJYhq8ZU6Jw+w0qFONqdMNkaglZebBE/1JUffaxWRIaNE7/k06Zxm8joh
N2fyaqWrRJCzF/puEyfznArVxzk3TxxX5s6TcGPrrjYQPr8LSrlT1Oh8niTK
Nzy+hCGJQgFQjUVYehq38f3jhS4mvNhQ9aLiiPyYjs9yhVnrix1mPOLiU4IN
5diTw1wV36TsdOxbeu1w+OJERUchYvR8nMlpx8NGNRSFl/WKQtw+Dhnk7sgQ
vUmlVOgp+FsJW75IN6RXGjiBgh1JppeL8UWM853f7gp8CvUgnq6DWnWFNXUs
/AuwkQT+wnwDBJaLEQVO555f0mScTYSYlI/Kyc7EDKW6zl/seW0yCE3PzImk
OpKnBOMhyJd0lvplNY04bDpVFePzZYmEi6P1R+OzrXIzayOn4TN5H+zxSEhP
kfUAWUf5J0TVyKFdEqbKr2/crKR2BhmmfAV1bskAyNkbp3dJ9RFD5PcPx1vY
m09VmcAQ6PuvRKHZeCjJOaY42ku13pQD66OYXuabea6WRFUqKiWvsFJklchr
lwPw2CsAnSA1X37ii3OJPZb3TTigjdPBZhqw2+beHMNAHW8GaAsN/9Merb7I
ISRQsii9pEoGou9LgHdx8gzV6tDK61w8J0jTxQvzfpDzDxaXk0GUvPZNqq7Y
w2qDMA1dG+Ss9PS1sOUirY+d0Gc68Sc0+18HXk24jC4AAA==

-->

</rfc>

