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

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

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

<rfc ipr="trust200902" docName="draft-dkg-tls-reject-static-dh-01" category="std">

  <front>
    <title abbrev="TLS clients reject static DH">TLS clients should reject static Diffie-Hellman</title>

    <author initials="D.K." surname="Gillmor" fullname="Daniel Kahn Gillmor">
      <organization>ACLU</organization>
      <address>
        <email>dkg@fifthhorseman.net</email>
      </address>
    </author>

    <date year="2018" month="December"/>

    <area>Network</area>
    <workgroup>tls</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft addresses problematic proposals that contradict the
expected security properties of TLS.  In particular, the ETSI
“Middlebox Security Protocol” standard deliberately weakens the
cryptographic guarantees of TLS unilaterally by the server, using
static Diffie-Hellman keys where ephemeral keys are expected.
Responsible TLS clients should avoid connecting to servers that appear
to implement such a specification.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>TLS 1.3 <xref target="RFC8446"/> promises strong cryptographic properties for a
two-party protocol.  These properties are the result of extensive
engineering and analysis, and are intended to afford users of TLS
baseline expectations of confidentiality, integrity, authentication,
as well as more subtle properties like replay resistance and forward
secrecy.</t>

<t><xref target="draft-green-tls-static-dh-in-tls13-01"/> proposed the use of a
pseudo-static DH share, and was discussed at length in the IETF TLS
working group as a mechanism to modify the security properties of TLS
for operations within the “enterprise datacenter”.  The working group
failed to reach consensus on this draft, in large part because of the
changes it created to the TLS security model, the relative lack of
cryptanalysis those changes have received, and the risks to users on
the broader Internet.</t>

<t><xref target="MIDDLEBOX"/> was recently formalized by ETSI, and offers a very
similar mechanism to <xref target="draft-green-tls-static-dh-in-tls13-01"/>. In
particular, MIDDLEBOX addresses none of the concerns raised during the
earlier discussion, and is not fit for the goals of TLS.</t>

<t>This document discusses how responsible TLS clients can avoid the
risks inherent in such a design, by refusing connections to peers that
implement it.</t>

<section anchor="key-words" title="Key Words">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
docuoment are to be interpreted as described in <xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="static-dh-problems" title="Problems with static DH">

<t><xref target="MIDDLEBOX"/> proposes the use of static Diffie-Hellman keys where TLS
expects ephemeral Diffie-Hellman keys.  Furthermore, it encourages the
sharing of those secret keys with third parties (“middleboxes”).  This
section documents some of the known problems with this design.</t>

<section anchor="limited-cryptanalysis" title="Limited cryptanalysis">

<t>TLS 1.3 as specified has been subject to a substantial amount of
cryptanalysis, including formal methods that provide security
guarantees.  Much of that cryptanalysis takes as a given that the
ephemeral DH keys are never re-used.  Deliberately re-using DH keys
invalidates some of this cryptanalysis, and discards the formal
guarantees provided.</t>

</section>
<section anchor="lack-of-forward-secrecy" title="Lack of forward secrecy">

<t>Standard ephemeral Diffie-Hellman key exchange permits simple forward
secrecy by means of each peer discarding the secrets used to establish
the session.  Reusing a DH key requires retention of the key, which
means that the expected forward secrecy properties are lost.</t>

</section>
<section anchor="confidentiality-violation-by-middleboxes" title="Confidentiality violation by middleboxes">

<t>A Middlebox which has access to the DH key of a given session can read
the contents of the messages in that session by deriving the
client_application_traffic_secret and
server_application_traffic_secret and using it to decrypt
ApplicationData messages.  This appears to be the stated goal of
<xref target="MIDDLEBOX"/> but typical TLS clients unwittingly connecting to such a
server may still expect confidentiality against third party
eavesdropping.  This implementation violates that expectation.</t>

</section>
<section anchor="message-tampering-by-middleboxes" title="Message tampering by middleboxes">

<t>A Middlebox which has access to the DH key of a given session can
derive all necessary secrets of the session, and is capable of
modifying messages in flight without detection by either peer.  This
violates the integrity guarantees of TLS.</t>

</section>
<section anchor="session-resumption-by-middleboxes" title="Session resumption by middleboxes">

<t>A middlebox with access to the DH key of a given session can derive
the resumption_master_secret, and can also view any NewSessionTicket
messages sent by the server.  The middlebox can use that information
to subsequently resume the client’s old session.  The middlebox can
also replay any application-layer data that the server might use to
establish client identity (e.g. passwords, HTTP cookies, or other
bearer tokens).</t>

<t>Since many TLS servers associate client identity with a TLS session
and/or application-layer bearer tokens, this effectively allows the
middlebox to impersonate the client.  This violates expectations of
authenticity (because the server does not know whether a resuming
client is really the expected client) and replay resistance (because
the middlebox can replay any application layer data sent by the client
to the server without the client’s knowledge).</t>

</section>
<section anchor="static-dh-implementations-are-error-prone" title="Static DH implementations are error-prone">

<t>Implementations of static DH schemes are known to be difficult to
implement correctly.  See for example <xref target="invalid-curves-TLS-ECDH"/>.
Proposals of this nature are likely to introduce new forms of
implementation error that would be avoided by standard
implementations.</t>

</section>
</section>
<section anchor="mitigations-against-static-dh" title="Mitigations against static DH">

<t>Given the concerns raised in <xref target="static-dh-problems"/>, responsible TLS
clients that want to provide the standard TLS guarantees need to
implement clear mitigations against risky peers.  This section
documents useful mitigations.</t>

<section anchor="tls-clients-must-reject-server-certificates-marked-for-use-with-static-dh" title="TLS Clients MUST Reject server certificates marked for use with static DH">

<t><xref target="MIDDLEBOX"/> suggests that most servers using the designated scheme
will use a certificate with so-called “VisibilityInformation” stored
in the <spanx style="verb">subjectAltName</spanx> X.509v3 extension (see <xref target="RFC5280"/>), as an
<spanx style="verb">otherName</spanx> field with a specific <spanx style="verb">type-id</spanx> of 0.4.0.3523.3.1.</t>

<figure title="OID of VisibilityInformation `type-id`" anchor="visibility-extension"><artwork><![CDATA[
    0.4.0.3523.3.1
    { itu-t(0)
      identified-organization(4)
      etsi(0)
      msp(3523)
      etls(3)
      visibility(1) }
]]></artwork></figure>

<t>A TLS client that receives a Certificate message from the server where
the end entity certificate contains any such element in its
<spanx style="verb">subjectAltName</spanx> MUST terminate the TLS connection with a fatal
<spanx style="verb">bad_certificate</spanx> alert.</t>

</section>
<section anchor="track-dh" title="Client detection and rejection of static DH">

<t>Annex A of <xref target="MIDDLEBOX"/> suggests that some servers may use
pseudo-static Diffie-Hellman without this <spanx style="verb">subjectAltName</spanx> in their
certificate.</t>

<t>To defend against leakage from these servers, responsible TLS clients
that can afford to keep state SHOULD keep track of the DH shares sent
by the server over the course of multiple connections.</t>

<t>If the TLS client notices that it has been offered the same DH share
more than once, it SHOULD terminate the TLS connection upon handshake
completion with a fatal <spanx style="verb">decrypt_error</spanx> alert.</t>

</section>
<section anchor="servers-must-avoid-accidental-dhe-share-reuse" title="Servers MUST avoid accidental DHE share reuse">

<t>Given the concerns in <xref target="static-dh-problems"/> and the necessary client
mitigations in the subsections above, servers need to avoid giving the
appearance of using non-ephemeral DH.  Servers MUST NOT reuse
ephemeral DH shares.</t>

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

<t>This entire document is an attempt to address security considerations
associated with the use of static Diffie-Hellman keys in TLS where
ephemeral Diffie-Hellman keys are expected.</t>

</section>
<section anchor="privacy" title="Privacy Considerations">

<section anchor="timing-of-rejection-for-detecting-dh-reuse" title="Timing of rejection for detecting DH reuse">

<t>Clients that are not careful with timing may introduce a minor
linkability concern when implementing the mitigation described in
<xref target="track-dh"/>.</t>

<t>Consider a network adversary with the following capabilities:</t>

<t><list style="symbols">
  <t>can observe some connections</t>
  <t>can actively interfere with other connections</t>
  <t>is willing to cause connection failures in order to link client sessions</t>
</list></t>

<t>Such an adversary may be able to identify a TLS client of a standard
TLS server across different connections by:</t>

<t><list style="symbols">
  <t>observing a successul connection, recording the server’s <spanx style="verb">server_share</spanx> value in the <spanx style="verb">key_share</spanx> extension to <spanx style="verb">ServerHello</spanx></t>
  <t>interfering sith subsequent connections to the same server from unknown clients</t>
  <t>each interference re-uses the server’s previously-offered <spanx style="verb">server_share</spanx> value.</t>
</list></t>

<t>If the client rejects this repeated share early (e.g upon receipt of
the <spanx style="verb">ServerHello</spanx>, but before the handshake completes), then the
network adversary can re-identify the client as being the one that saw
the share recently.</t>

<t>Note that this linkability attack is mitigated by waiting until
handshake completion to reject the server’s offer, since a normal
network adversary does not know the server’s credentials, so it will
not be able to complete the handshake legitimately.  So rejection of
the connection at end of handshake will not allow the server to
distinguish the specific client from any other TLS client.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>There are no IANA considerations for this document.</t>

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

<t>Thanks to numerous commenters on the tls@ietf.org mailing who
explained why using static DH presents a risk to TLS users.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC5280" target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>



<reference  anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>


<reference anchor="MIDDLEBOX" >
  <front>
    <title>Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control</title>
    <author >
      <organization>European Telecommunications Standards Institute</organization>
    </author>
    <date year="2018" month="October"/>
  </front>
  <seriesInfo name="ETSI" value="TS 103 523-3"/>
</reference>


    </references>

    <references title='Informative References'>

<reference anchor="draft-green-tls-static-dh-in-tls13-01" >
  <front>
    <title>Data Center use of Static Diffie-Hellman in TLS 1.3</title>
    <author initials="M." surname="Green" fullname="Matthew Green">
      <organization></organization>
    </author>
    <author initials="R." surname="Droms" fullname="Ralph Droms">
      <organization></organization>
    </author>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization></organization>
    </author>
    <author initials="P." surname="Turner" fullname="Paul Turner">
      <organization></organization>
    </author>
    <author initials="S." surname="Fenter" fullname="Steve Fenter">
      <organization></organization>
    </author>
    <date year="2017" month="July" day="03"/>
  </front>
</reference>
<reference anchor="invalid-curves-TLS-ECDH" >
  <front>
    <title>Practical Invalid Curve Attacks on TLS-ECDH</title>
    <author initials="T." surname="Jager" fullname="Tibor Jager">
      <organization></organization>
    </author>
    <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
      <organization></organization>
    </author>
    <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
      <organization></organization>
    </author>
    <date year="2015" month="September" day="14"/>
  </front>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIADtXB1wAA61a63IbOXb+j6dAaX6snVIrkmUnM0pt1SqSZ6wdS3YsTbKp
VMoCu0ESw+4G0+gWzVVpHmtfYF8s3zkH6Asle+xUXC6b7AtwLt/5zgXMsky1
ri3tib55e63z0tm6DTosfVcWurG/2rzVoTWty/W5m8+dzd7YsqxMrcxs1ti7
6Xs7L7xRhc+vTIXVi8bM26xYLbK2DJk8l8lzWbHMDo9UYVo89+Lw6Pvs6IXK
8W3hm+0JFiuUcuvmRLdNF9oXh4c/HL5QprHmRF/ZduOblaJ/Fo3v1nioDGpl
t7hSnOiLurVNbdvsnLZXChvWxUdT+hpbbW1Qa3ei/6v1+b4OvmkbOw/4tK3o
w38rZbp26ZsTpTOltavDiT4/0D8f6J8cTOAbXKxZuXNTO1vqn82yHt3zzQLX
/woVfX2i907P3v6yh8u2Mq7Ed9jiT3M3b5fYIuBifQBB95SqfVPhnTuLfT/8
ePbi6OgH+fTqxfeH8un7ly//CZ8uL87P377+13d/wWcdvbh36YqitDP/SV/b
vGtcu9XvGw8Vffkv+r1pWn18QlfmrrR67httyUbrxgWrazGnhpE03GF0jpuN
1SbPbQg69/jmS1Ji7KxDfO8txWqf6Ndd49fW1PrGljb3VdXVLmdLBH1NTjBN
EeCeALG71uK9YBtng6vnnld5fXN9AWxd66PDY/3qxXF2DBDg5mAbQdSisbZm
TA1gcnzh6BioGlnmnBQ6Y211B2X9nCR5DGw4mjF9dHA8VvSfs0P8PZ7qmkUA
XJq2XdqN/omkGd/4YMr1Up83vgqTyx3M+cZ3obTb8fX3piv1TQfINuPL1629
s/pHll1BvjtTuiKDd+9syCBr9vrs/M1I1feNyaGYKWFhflaf0bP6tG1Nvgra
s4b81ljFV9nhD9nRy6dVvHEzgOXPZjEV7c9//1uz0Nf5cmPr1eRG15hf9bVH
LPi7sNoqlWWZNrPQknBK3SxdEB9qUxQN8GWDXjd+VtqKvYLPax9MGXS7NK2A
zxQO9AJTK/tpDQaxBXATUU7P26YFiMi10O9AQ329BuRd3pWm2acXGVjqS1Gy
p0MEqC5s6Wa2gX3Krd5Ys7J14N3zZrtu/aIx6yUkXXSmMfBNv7MG2ku81ZgS
L862vDEAfmchRAeQL9STnKpBXEFvlhYxZ9dLW9EKctHQpajzgfpgwxqh5GCs
p3jb3Hn4HBar8Tx2062P20djmjWCs1G47Ko1DI6XdejypTY6YA83j8F6IF6r
2FpKXVD8F11Ot9QfR3/gTokYfX8f+enhgTxSOXIrfO4hxdRqI38RDRkF7snI
W+xKdgU8eLO0iNXRs2QIMicQ05UtGdx+auEXkIKy9cLVFkSCzYjDTG3KbXDg
dP6GNx3cVBeADVQ3c+xbEBc0yXFqZgJ8XidbR8bCTRhz7grYySGe2u0+r7Ro
+CNFC90Rm+0rAx/CoRr/A/3wfDdDWI6VKN2KNFiXZkuKOEJcbllKyLQB9hRw
3dh8Cw/c338V1YnBETKkHQwUOc6odbBd4bM+KQMlMIXYZAMZCxdy8BFeAzJK
2LBdEgfSGhevb35ku1BaIKtykiXFjK5svkR+CxXZsvKFmyecfy4gFfmZrkWz
bly7jBvtjbIQZZ6cv+8JAPRkdzVH/hQPogYAZuGaAAB0zGttTyvkIo2wX1jm
AD2zuYk24RCG8AuI5kAtWKeVFUkWgnKvBBSz5X5EXMm5B4vmKywjLJAwhkdg
ep2WXZo7eiO3eKEQW/MaLoB/sVFEXa3o6qzxpkBaSuUKO73P7nAsuYkWq1vw
CSfB0v0VEoNaiM9kfT+f05pGI863KrgKHNRM3fTVUDqALGpMnb00I7auUUZF
c5ITcsgOMY0jKBUdRyFTtWlAT03CGYUIy+tohVbP4QECBq2y8MT3kb5TjvB5
xwSVcArj+g2FzZMUmINGhf9ob7G3q4lSsQQQEWmuQNQtIMiMAnDOnNwTJmET
xlrbxJdqYElHzvnZbvV/gDsCsaP8IWEtUTWBFaXN3uUv1zd7+/K/vnrHnz+8
/rdfLj68PqfP129O377tP8gTCl/e/fI23qdPw5tn7y4vX1+dy8uXp/+5J0bc
e/f+5uLd1enbPYlZF6jm7jwLy1zpgXxmK4SXJZhTyNuQN0htBb3ElE1lJtyu
1HtJwRKdQyWv9f13A1Zing4PkywwSQhTAEdmCmNm+t0USJQhPBxG6fCJ50ET
P3YNlm6Ib/cppm2de1QgC9lSEeWRixmtFKdMr23cjTSF6ZAMGPJ459lelSoE
G/aeMw/BtEHg0WMSqQ2WTjGwqv2mTjXMsGyIYINx3yIoyQUT5hhANP4zpFT4
KyZlvLnEtxmCl5IK91qUyOgLpRBKTtpUvqvbR/xEdJiXXUFWEAYBNcAWRSwJ
IPYdElzPfGqoaqD9JUUNq0ml2JT3UBYFSQkLkF0tz3DgDz57M1QxNWrZBkGX
AQYFlj4fF1l8mUSMb6hY7OLu2NbYdkc5bllAENxXkDNEx5EWScOC/CAMnpKt
jsn2aU+QL1LP8kUcomgQ+gd1NHA0JGbi2M3pRDoVmiNmOk5hRDVJ/EibEaGB
ooVTk4WHZ6ULSyV3mUlhvw9WLGaizWDD/+kc6FFTuNeM1wRQi2plg+JrqWT/
5Kq+tNy1yG7lVfpABHg2rYb0nfMlJ3VWbYiczxn0CQuf6qEmZxEZ6rHzjJk5
KkhVTcRaNAOzPrJ4oWIuajk4o9oVHmImcBGc6S0Ii7Tr7lKmkhzyEdVxGYu5
j+g54Ob8Y+QLoEBJJf07T0mZT0wE2QvLaFWnwyvcjSbBIr3EsjxEzmY3t1yZ
UF6kiJ6S6qzD6ts1N3rjFNjVoB6q+xFQO00AJ7+oga5QfaIBR6Uq7t8tcrVZ
GIcWfcSNW2RzNJ0FULHGmknwPj8KCAQONuJrVEoDOpeiM2ijWkul/o2Q+X+A
imKvo96G6rAOSdRs+4CLqInP97VKbtaGig24Qapdkn0MrXnpFsuWad/DMwWi
L08xYR1lJ47zlEtGRrJDN/G4mYTNrqPo1PNU6/9TnJHVqsFqlJq+JbbEYCo1
XiLEx8oElBUR9WIoLr/K4IEBu8GVrb6ymyj/jctXtlW9zQLVKJPuONb7g6C0
HJULDKR+/kNls+ekB6qTopilkpiRMPgD7FcWI558tLBiOWMXRpKOIjrDNaJk
itKeJFPYsJtZKq96Vo7baokfOPKZPUB8rE0IXBHu6zc3N+8RYn4FMt3X1AoR
JtQMIY9VW0/ThefkbUe9YEUSSSsijTsW8rkDYh7tJN6MD7O6Cq74R2qqH2k0
2W1fUqlF45BTZwM7IiT8RmqmwVgyJ4AQvqb9ByOn+O+xvNM2q741ZoukFmxk
zMJbaQOoeKK6j+PEiD9pUJKUpXTG45RJupK7zxl6j/vptCHjdgqqp92uR24f
o1O2UTFUougp0CeYIzXQnS4se7KvnqcEGcc5TeMbKqVr+9V5EnF8sbPUqJJG
a59TeSLrSzkquaSgYiWngQkwO3QzuW+Q5RE/cOS1jfPgT4aLlvv7zwwaqU14
3w/nUj0GZHQ0KqYiwa0ISoSaODCiqm/DJRmjYiddsCEkzDY8v4LA3MJJh5vG
cTuvBUomrnWLZNKYrIbDh8/0JqlD+SlWq4+bV26Knuh2HvZ3206Vcq5ID+Lm
zjHW0jGDS+VI4Tki99pyWTd2RmmpX39CJepit9KPpoiLnYgaOhHgfN6V4/cP
pIc4iyJyJ/ohntAIhHMq7XjYB4kq06ykAmRym/Z/X4/Q30fwtIoJ3QLJIJmw
8qHtKU9qKLKidFBcCwnE1YbqFpLTjLWIUvsMNRENifb+3cFXjqqZiyF70IgX
jSIQJf6/jc3UadnSadWt/svBq8Mf7o7TaBEYfRaslU6ZjmEeHp7vc8tTq1tm
cXkN/QDQG+k4DVL1LWo0m7nilmLl8ODlweHB8asXxwfHB0fw0G+//UZj850b
fOke5WOXtc8On/NXHRmf+sBsfLj07GV6AOWLGx6vwvoZLTjcLcOz/ttdb5ln
R8/1Awtyf6K/G65ng/p8sPDHvXcX56TEk0Yd9Nx7UFRuDCWpuDZOw6hRPBt5
LJYDet74akKvNANg5rYg95jqxq6mMp/ig0mcK1ubhjQ1LBfUI7dyBLTUm/V5
jIXs5z7Jd3MkgFLdzkzxcbTjLbIjvlH/I2oNJZ7kn1/jtwkl339HJx4rEMnD
twQRLAipPulTWu1LEcNdcYoYKukp4e3MfKet6pC4QCSPjCQx4Ro10pyYhNqY
ObkisRLoajV2XOjFeESTqTVRMj+gGlGG7yDLlbVr6XN0nHnxFTZaqsXT0Fpq
RjWpGbWnf4TGu0ZGSxUynaMkNhrpQYeL+eBz8SAqD5enRgXNWj9e4WFqnKQH
2KUXQfFIH8/jGWQNHjZFub+IrA72wPJ1gVVWaDU98f4jzOnb2Ct+5KQ4IO46
OpghLPNN1O9MCDxfeS3SwfDk/m8k5Ccy4WdTYD/KHhqnWB2NM1ckVi7R40TV
zOCo/R6pMf9FXRZDEy5NMNdv8KSkgBr163iaxOXKyCBX726i5pOZk2CGrRfH
+WcEyqI/geCpZrz3hVkmZ1xiIBi4H0dTvw4ct61FN8SayGB8ODvIJ5upvoAv
0mjwa0ah8TRa2PCLU9CdM0LUaO7O5E/qvJZbn1MZGrsqjksHVqPCIDKeDOi+
FWuJN9MhJA0DPdFBw5WLGEU2Jh4bikeDqqb2jSpdvTKSeBJSyTD1UF6nemHA
4mTWjdKjJ+MHmWOxabBD/9uHgmBFsO6dNPfUFPEJAc0AaH+0cCdK6X9gLvMz
BrUw8Yhx0n2TmiuewhOvyNpcOey+4GhwXJZxYCP90ohG6PCra2TgAALlVk6T
XRKjxQ4wAPQ87KlHGpFVqbYmVqbqXMqJbewd4wI8Aehr7qEDhRqND4FbCTlN
GZ+XzLZiD7GFzCORk4ki4NrhSUoN6DpGU05a+w+Uh2SsxjF7q9F5dDbRyC3g
nW6MahKvb4UFKAr8LVsvWpiWD1wK9kOC3eOdntmjepzGulq6ppSvsCQPaHvP
ES3J7DpM5V83Fl1wF8ptlnLHUyoNWSiaW+IrSDJGVypHkULmdHImgwRJH1xB
rXm2z2YZa7/P48CZnft4QN7nGh1zjQ3P+SCTbaoe413a4qxHxUhIzorJZXTq
J5WH2cgsOmYeOZ+Ehle+tWls4oIeh63hn6AQymOISo+3MY5jt8PWpXokenR3
/HnZxO5sbKQVHpogjGXs/1i76aBhskQOZ8nQk3795SmjUwgqenoULsmMO9Yt
7QKyV3x+QXnJTwrBNJBO8UvzUD6rHa3ArQxtxsOXcWmD/rBwgSzT0YiJ76S2
IrqGYUsVsLDJEMjww3f64vTqdCcB8Ell7NRrL09MM1U8jh2dvfJap3k/3OCO
kxYytRxn13isAfrJSBWf3cfTeEs/yPuTs+38AC2Lpt++kZ83S09HeyUqSUqH
y21M9EPZjHgKnCsMt7+0Cf+yhs7N489SZkCS+l+Jelu9wigAAA==

-->

</rfc>

