<?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.8 -->

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

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

<rfc ipr="trust200902" docName="draft-rescorla-quic-over-dtls-00" category="info">

  <front>
    <title abbrev="QUIC/DTLS">QUIC over DTLS</title>

    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>RTFM, Inc.</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date year="2018" month="March" day="05"/>

    <area>General</area>
    <workgroup>QUIC Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>QUIC in-band cryptographic negotiation on stream 0 creates a number of odd
edge cases. This document considers an alternative design in which QUIC
transport is run directly over DTLS, thus separating the cryptographic
negotiation from the transport piece.</t>



    </abstract>


  </front>

  <middle>


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

<t>QUIC <xref target="I-D.ietf-quic-transport"/> <xref target="I-D.ietf-quic-tls"/> as currently
designed performs cryptographic negotiation by sending TLS 1.3
<xref target="I-D.ietf-tls-tls13"/> traffic directly in stream 0.  This design was
the result of desiring to have tight coupling between the
cryptographic handshake and the transport and has a number of
advantages in that it allows the TLS 1.3 flow to take advantage of
QUIC’s transport services, in particular reliable in-order delivery,
RTT estimation, etc. However, it also results in several unpleasant
corner cases:</t>

<t><list style="symbols">
  <t>The cryptographic handshake stream is subject to a variety of odd rules,
such as:
  <list style="symbols">
      <t>Stream 0 is unencrypted at the beginning of the connection, but
encrypted after the handshake completes.</t>
      <t>Stream 0 is not subject to flow control; it can exceed limits and
goes into negative credit after the handshake completes.</t>
      <t>Retransmission of stream 0 frames from lost packets needs special
handling to avoid accidentally encrypting them.</t>
      <t>Stream 0 offsets are reset after the server sends a Retry packet.
This creates special handling rules for the stream.</t>
    </list></t>
  <t>The QUIC stack needs tight coupling with the TLS stack to know, for
instance, whether the TLS stack sent SH or HRR, or where the boundaries
are between flights. See, Issue #1094 for an example of this kind
of problem.</t>
  <t>There are complicated rules about which packets can ACK other packets,
as both cleartext and ciphertext ACKs are possible.</t>
  <t>The interaction of the state machine advancing (which makes clear that
packets have received) and ACKs is confusing. For instance, it is
possible to respond to an Initial packet but not ACK it. The semantics
of this are unclear.</t>
  <t>There are complicated rules for how to handle 0-RTT (and especially
0-RTT failures).</t>
  <t>The stack needs to continue to service stream 0 indefinitely in
order to gather NewSessionTicket messages.</t>
  <t>QUIC version negotiation isn’t authenticated, so it is retroactively
authenticated during the TLS handshake.</t>
</list></t>

<t>This document considers a design at the other end of the spectrum,
which is to layer QUIC transport over DTLS 1.3
<xref target="I-D.ietf-tls-dtls13"/> (with some small pieces of coupling). This
design addresses most of the corner cases described above, although it
does introduce some new issues which must be considered.</t>

</section>
<section anchor="design-overview" title="Design Overview">

<t>The current QUIC/TLS integration treats TLS as a module
which gets a lot of its services from QUIC. I.e., something
like this:</t>

<figure title="Current QUIC Architecture" anchor="fig-quic-arch"><artwork><![CDATA[
                     +-------+-------+
                     |  TLS  | App   |
                     |       | Data  |
   +-----------------+-------+-------+
   |  Other Frames   |    Streams    |
   +-----------------+---------------+
   |              Envelope           |
   +---------------------------------+
   |                UDP              |
   +---------------------------------+
]]></artwork></figure>

<t>This creates a
relatively complicated interaction, as shown in the following
diagram from <xref target="I-D.ietf-quic-tls"/>.</t>

<figure title="QUIC/TLS Interactions" anchor="fig-quic-interactions"><artwork><![CDATA[
   +------------+                        +------------+
   |            |------ Handshake ------>|            |
   |            |<-- Validate Address ---|            |
   |            |-- OK/Error/Validate -->|            |
   |            |<----- Handshake -------|            |
   |   QUIC     |------ Validate ------->|    TLS     |
   |            |                        |            |
   |            |<------ 0-RTT OK -------|            |
   |            |<------ 1-RTT OK -------|            |
   |            |<--- Handshake Done ----|            |
   +------------+                        +------------+
    |         ^                               ^ |
    | Protect | Protected                     | |
    v         | Packet                        | |
   +------------+                             / /
   |   QUIC     |                            / /
   |  Packet    |-------- Get Secret -------' /
   | Protection |<-------- Secret -----------'
   +------------+
]]></artwork></figure>

<t>In the design proposed by this document, we have a more natural
layered structure, similar to that of HTTP2 over TLS. I.e.,</t>

<figure title="QUIC over DTLS architecture" anchor="fig-quic-dtls-archt"><artwork><![CDATA[
+-------------------------+
|          QUIC           |
+-------------------------+
|          DTLS           |
+-------------------------+
|           UDP           |
+-------------------------+
|           IP            |
+-------------------------+
]]></artwork></figure>

<t>Of course, you still need some signaling between QUIC and DTLS,
but it’s largely the conventional signaling that any application
protocol over TLS needs. Specifically:</t>

<t><list style="symbols">
  <t>It’s possible to send data (in 0-RTT or 1-RTT)</t>
  <t>The handshake is complete</t>
  <t>Here are the cryptographic parameters</t>
  <t>The record number that corresponds to a given piece of data.</t>
</list></t>

<t>The only real special accommodation needed is to carry the
QUIC transport parameters, which you already needed in the
current design (although it’s not shown). You may also
want to expose DTLS’s RTT estimates to QUIC
(see <xref target="rtt-estimation"/>) but this is not necessary to have
a functional system.</t>

<t>Operationally, this is straightforward. You negotiate DTLS and then
send QUIC frames over DTLS as type application data, as shown
in <xref target="fig-1-rtt"/>.</t>

<figure title="Simple QUIC over DTLS" anchor="fig-1-rtt"><artwork><![CDATA[
     Client                                           Server

     CH -------------------------------------------------->
     <------------------------------------------ SH ... FIN
     <-------------------------------------- [ QUIC frames]
     FIN ------------------------------------------------->
     <------------------ [QUIC frames] ------------------->
]]></artwork></figure>

<t>The payload of each application data DTLS record consist
of QUIC frames laid end to end, precisely as in current
QUIC packets. Because DTLS application data is always
encrypted, this means that the QUIC frames themselves are
also encrypted.</t>

<t>When 0-RTT is used, things are as you expect, namely that QUIC frames
can be sent in the early data, as shown in <xref target="fig-0-rtt"/>. If 0-RTT is
rejected, then the frames can just be treated as lost and
retransmitted, though you probably want to do so immediately and some
care must not be taken to let this modify your congestion state.</t>

<figure title="QUIC over DTLS with 0-RTT" anchor="fig-0-rtt"><artwork><![CDATA[
     Client                                           Server

     CH -------------------------------------------------->
     [QUIC frames] --------------------------------------->
     <------------------------------------------ SH ... FIN
     <-------------------------------------- [ QUIC frames]
     FIN ------------------------------------------------->
     <------------------ [QUIC frames] ------------------->
]]></artwork></figure>

<section anchor="reliability" title="Reliability">

<section anchor="dtls-reliability-and-acks" title="DTLS Reliability and ACKs">

<t>In this design, DTLS takes care of its own reliability for the
handshake (and for post-handshake messages) via a timeout and
retransmission scheme, including ACKs. DTLS ACKs apply only to
handshake records and so simply don’t apply to QUIC frames at all.
DTLS ACKs apply to both encrypted and unencrypted handshake records.</t>

</section>
<section anchor="rtt-estimation" title="RTT Estimation">

<t>One virtue of the current deisgn is that you get an RTT estimate
from the QUIC congestion control machinery for packets that are
sent during the handshake phase. Naively you would lose this,
but DTLS actually gives you a primitive estimate of this via
its own reliability mechanisms and ACKs. So the natural thing
to do here is to have the DTLS implementation derive an
RTT estimate from the DTLS handshake from the first round
trip in each direction and then provide it to the QUIC
part of the stack as an initial estimate.</t>

</section>
<section anchor="quic-reliability-and-acks" title="QUIC Reliability and ACKs">

<t>By contrast, QUIC ACKs only apply to application data records
(which contain encrypted QUIC frames) and are just sent with
whatever the current DTLS epoch is.</t>

<t>One subtlety here is what the QUIC ACKs acknowledge, because
we no longer have QUIC packets. One way of handling this would
be to have packet numbers as a header inside each application
data record, i.e.,:</t>

<figure><artwork><![CDATA[
[Packet Number] [Frame] [Frame]... [Frame]
]]></artwork></figure>

<t>However, this wastes space, so a better approach is to just refer
to the DTLS record number. This is the primary piece of layer violation
in this design in that the QUIC stack will need to be aware of:</t>

<t><list style="symbols">
  <t>Which DTLS record number a given frame went out on</t>
  <t>Which DTLS record number a given frame came in on</t>
</list></t>

<t>This is a tiny bit ugly, but isn’t complicated to implement.</t>

</section>
</section>
<section anchor="version-negotiation" title="Version Negotiation">

<t>In current QUIC, you negotiate two versions:</t>

<t><list style="symbols">
  <t>The QUIC version by having the client propose a version and
then the server corrects it.</t>
  <t>The TLS version which is negotiated by having the client
propose all its versions and then the server selects one.</t>
</list></t>

<t>When we reorder QUIC and DTLS, a different design is appropriate.
DTLS currently doesn’t encrypt the ClientHello, so obfuscation
does not immediately become an issue, and instead we can have
both QUIC and DTLS versions negotiated in the customary way,
namely: the client proposes two sets of versions:</t>

<t><list style="symbols">
  <t>DTLS versions in “supported_versions”</t>
  <t>QUIC versions in “quic_versions” (new)</t>
</list></t>

<t>And then the server chooses its preference for both of them.</t>

<t>Assuming that we want to continue to have handshake obfuscation,
we will need to modify DTLS to allow this (more details about
this in <xref target="dtls-obfuscation"/>), and then we can adopt the
current scheme with a small set of modifications.</t>

<t><list style="symbols">
  <t>The records containing the ClientHello and ServerHello
contain a DTLS version. This reflects the version of DTLS
whose obfuscation constants are in use.</t>
  <t>If the server recognizes that version, then it simply
decrypts the handshake messages and does DTLS version
negotiation mechanism (see <xref target="fig-vn-success"/>).</t>
  <t>If the server doesn’t recognize that version, it sends
a VN packet as with current QUIC (we would need to add
this to DTLS). The client then re-sends the ClientHello
except obfuscated with a different version. Note that
you use the same ClientHello.supported_versions and
so an attacker cannot impact DTLS version negotiation
(see <xref target="fig-vn-retry"/>).</t>
</list></t>

<figure title="Version negotiation with compatible obfuscation" anchor="fig-vn-success"><artwork><![CDATA[
     Client                                           Server

     CH version = A[supported_versions = A, B, C] --------->
     <--------------- SH version = B [supported_version = B]
]]></artwork></figure>

<figure title="Version negotiation with incompatible obfuscation" anchor="fig-vn-retry"><artwork><![CDATA[
     Client                                           Server

     CH version = A[supported_versions = A, B, C] --------->
     <--------------------------------- VN versions = [B, C]
     CH version = B[supported_versions = A, B, C] --------->
     <--------------- SH version = B [supported_version = B]

]]></artwork></figure>

<t>Note that this design is 1-RTT faster than the current design in
cases where the server has changed it’s preferred version. In
current QUIC, that results in a VN, but here the server can
just remember the old constants, decrypt the record, and proceed
with negotiation as usual.</t>

</section>
<section anchor="transport-parameters" title="Transport Parameters">

<t>The QUIC transport parameters can be negotiated in DTLS extensions
as they currently are.</t>

</section>
<section anchor="key-changes-and-new-session-ticket" title="Key Changes and New Session Ticket">

<t>Because the QUIC frames are carried over DTLS, the DTLS stack
naturally reads and writes DTLS records that are not carrying
application data (primarily handshake) as well. This means
that post-handshake messages such as KeyUpdate and NewSessionTicket
just work naturally: the peer sends them and the DTLS stack
consumes them, transparently to the QUIC stack. Note that this
is an improvement over the current design, in which the
QUIC stack needs to continue to pass data back and forth to
the TLS stack on stream 0. Key changes just take effect according
to the DTLS schedule.</t>

</section>
<section anchor="connection-ids" title="Connection IDs">

<t>DTLS 1.3 has no native support for connection IDs, but instead has
farmed it out to a separate draft <xref target="I-D.ietf-tls-dtls-connection-id"/>.
That draft takes a slightly different strategy from QUIC in which
both sides provide the connection ID for the peer to use to send
to them. However, we are currently considering precisely such
a design in QUIC (see https://github.com/quicwg/base-drafts/issues/1089)
in which case, much of the design would drop into place.</t>

<t>The remainder of this document assumes that we are using asymmetric
connection IDs, as that seems like the direction we are going, but
this part of DTLS is still under active design and so could presumably
be modified to support QUIC’s needs.</t>

</section>
</section>
<section anchor="dtls-changes" title="Required Changes to DTLS">

<t>Some modest changes would be needed for DTLS to ensure parity with the
current QUIC design. These changes would reuse design work we have
already done for QUIC.</t>

<t>In addition to the existing DTLS 1.3 capabilities and the connection ID
work, the following changes are needed:</t>

<t><list style="symbols">
  <t>Handshake Obfuscation, <xref target="dtls-obfuscation"/></t>
  <t>Obfuscation Negotiation, <xref target="dtls-obfuscation-nego"/></t>
  <t>Packet Number Encryption, <xref target="dtls-pn"/></t>
  <t>Stateless Reset, <xref target="dtls-reset"/></t>
</list></t>

<t>These would each add a generic capability to DTLS that could be used
by other protocols.</t>

<section anchor="dtls-obfuscation" title="Handshake Obfuscation">

<t>As noted above, DTLS does not presently encrypt the ClientHello
and ServerHello messages (the remainder of the messages are in
the clear). However, there’s an elegant way to handle this,
as suggested by Martin Thomson, which is to define the format
of DTLSPlaintext as being version specific. Recall the standard
DTLSPlaintext:</t>

<figure><artwork><![CDATA[
    struct {
         ContentType type;
         ProtocolVersion version;
         uint16 epoch = 0                                 // DTLS field
         uint48 sequence_number;                          // DTLS field
         uint16 length;
         opaque fragment[DTLSPlaintext.length];
     } DTLSPlaintext;
]]></artwork></figure>

<t>We can simply declare that when DTLSPlaintext.version is set to 1.3 or
above, we instead have:</t>

<figure><artwork><![CDATA[
    struct {
         ContentType opaque_type = handshake; // Real CT inside the encryption
         ProtocolVersion version;
         opaque dst_conn_id<0..255>
         opaque src_conn_id<0..255>;
         uint16 epoch = 0                                 // DTLS field
         uint48 sequence_number;                          // DTLS field
         uint16 length;
         opaque encrypted_record[length];
     } DTLSHandshakeCiphertext;
]]></artwork></figure>

<t>This format would be used only for the initial handshake and any alerts or acks
it generates (i.e., data in epochs 0, 1, and 2). For epoch 0
(what would be plaintext in TLS 1.3),
the obfuscation is done essentially as with QUIC, i.e., with a KDF
keyed with a per-connection function and the dst CID. For all other epochs,
you encrypt just as you would with DTLS 1.3 today.</t>

<t>Note the difference here from TLS 1.3 in which these packets get
type=handshake, which with the record version tells us that the CID
variant is in use.</t>

<t>Note that this is essentially the same structure here as I recently
proposed for asymmetric CIDs.</t>

<t>An advantage of this design is that it has a natural “backward
compatible mode” for DTLS where you can use the old format
if you don’t know what the peer supports (conventional D/TLS
behavior) but if you have a minimum version that’s 1.3 or above
you can get obfuscation.</t>

<t>[[OPEN ISSUE: Grease the length bytes.]]</t>

</section>
<section anchor="dtls-obfuscation-nego" title="Obfuscation Negotiation Packet">

<t>In the case that the client chooses an obfuscation scheme that the server does
not understand, we need a way for the server to request a different obfuscation
scheme.</t>

<t>This is analogous to the QUIC Version Negotiation packet, but it only
negotiates the choice of obfuscation. Because it is separate from the
negotiation of the QUIC version, it can be much lighter weight.</t>

<t>We can more or less directly steal the QUIC Version Negotiation scheme. That
is, the server sends a list of supported versions in place of the packet
payload:</t>

<figure><artwork><![CDATA[
    struct {
         ContentType opaque_type = handshake; // Real CT inside the encryption
         ProtocolVersion version = 0;
         opaque dst_conn_id<0..255>
         opaque src_conn_id<0..255>;
         uint16 epoch = 0                                 // DTLS field
         uint48 sequence_number;                          // DTLS field
         uint16 length;
         uint16 supported_versions<2..254>;
     } DTLSObfuscationNegotiation;
]]></artwork></figure>

<t>Unlike the current design, where authenticating version negotiation is
critical, a downgrade attack only causes the ClientHello and ServerHello to
be protected with a different obfuscation scheme. Because obfuscation does not
affect the integrity of the protocol negotiation there is no need to add
separate authentication for this exchange.</t>

</section>
<section anchor="dtls-pn" title="Packet Header Encryption">

<t>DTLS does not encrypt its packet number and also does not presently
have sequence number gaps, which makes changing connection IDs for
privacy of modest value. There’s no reason we couldn’t adapt the
same techniques we have discussed using for QUIC, when we
get those nailed down. Pretty much all the same issues apply to DTLS and
QUIC here.</t>

</section>
<section anchor="dtls-reset" title="Stateless Reset">

<t>As noted above, we would need to define stateless reset. The best way
to do this is to define a new extension in Encrypted Extensions
for this, so that it’s usable for non-QUIC purposes. Otherwise
the mechanics can be identical to the current QUIC design in
Section 7.9.4 of <xref target="I-D.ietf-quic-transport"/>.</t>

</section>
</section>
<section anchor="required-changes-to-quic-documents" title="Required Changes to QUIC Documents">

<t>Obviously, we would require changes to the existing QUIC drafts to
make this work. Primarily it’s a matter of removal. This section
covers the known changes.</t>

<section anchor="tls-document" title="TLS Document">

<t>This document is just removed entirely. We don’t need it any
more. This removes all or nearly all the crypto from QUIC,
and in particular the somewhat complex key schedule, and leaves it in DTLS.</t>

</section>
<section anchor="transport-document" title="Transport Document">

<t>Much of this document also goes away. Specifically:</t>

<t><list style="symbols">
  <t>We are folding the entire QUIC header into the DTLS header (and
stealing a lot of stuff in the process) so basically all of Section
5 (Packet Types and Formats) away.</t>
  <t>We carry frame types directly over DTLS, so Section 6 (Frames and
Frame Types) stays,</t>
  <t>Essentially all of Section 7 (Life of a Connection) disappears, and
is replaced by the DTLS CID and new version negotiation scheme
carried in DTLS extensions (see <xref target="version-negotiation"/>). The
connection migration design works without modifications, so that
would be retained. Similarly, once the DTLS connection is
established, QUIC style connection close should be used, with
the exception of stateless reset and (optionally) if the DTLS
layer decideas to abort because of too many deprotection failures.
The DTLS close_notify was intended as unreliable and is therefore
less capable than QUIC’s close.</t>
  <t>As noted above, ACKs stay essentially the same, but we will need to
change the encoding a bit to handle epoch changes, as described in
<xref target="quic-reliability-and-acks"/> and <xref target="epoch-and-acks"/>.</t>
  <t>Section 9 (Packetization and Reliability), 10 (Streams), and 11
(Flow Control) also stay the same.</t>
  <t>We’ll want to trim down the error space (Section 12) a little bit
because we’ll want to use DTLS alerts for a lot of errors. This
makes things easier because it avoids the confusion we have now
about whether to send a QUIC error or a TLS alert.</t>
</list></t>

</section>
<section anchor="recovery-document" title="Recovery Document">

<t>Almost no changes, except for the rules about handshake recovery.</t>

</section>
<section anchor="invariants-document" title="Invariants Document">

<t>We will need to modify the invariants to match the DTLS invariants,
but the principles are the same and the header/packet formats are
reasonably similar, so this should be straightforward.</t>

</section>
</section>
<section anchor="potential-additional-benefits" title="Potential Additional Benefits">

<section anchor="record-coalescence" title="Record Coalescence">

<t>One challenge in QUIC has been that it is not possible to place two
QUIC packets in the same UDP datagram. This creates problems whenever
you would like to have two packets encrypted under different keys
sent together, as with the Initial packet and 0-RTT data, or with
1-RTT data (which is encrypted) and the Finished message (which is not).</t>

<t>With DTLS, however, this is straightforward. DTLS has three record
header formats:</t>

<t><list style="symbols">
  <t>DTLSPlaintext</t>
  <t>DTLSCiphertext</t>
  <t>DTLSShortCiphertext</t>
</list></t>

<t>The first two of these have built-in length field and can therefore
be packed more than one to a UDP datagram. This allows for simple
piggybacking of records of different types. Obviously, this header
engineering could be done for QUIC, but its not something we
have done.</t>

</section>
<section anchor="more-straightforward-demuxing" title="More Straightforward Demuxing">

<t>We have had extended discussions about how to demux QUIC with
other UDP protocols which might be on the same 5-tuple
(principally for WebRTC). Because the existing cases already
use DTLS, carrying QUIC over DTLS obviously makes this easier.</t>

</section>
</section>
<section anchor="potential-points-of-concern" title="Potential Points of Concern">

<section anchor="record-sizeoverhead" title="Record Size/Overhead">

<t>One concern we might have is about record overhead. It’s a bit
hard to make a straight-up comparison between QUIC and DTLS 1.3
because they make different assumptions about the length of
the sequence number field. As noted above, DTLS 1.3 as currently
proposed has two different header formats. The longer of the two
has a 7 byte header with a 30 bit sequence number and a length
field. The shorter is only two bytes with a 12 bit sequence
number and no length field. In addition, DTLS 1.3 has
a one byte internal content type field that is used to
distinguish application data from handshake data and to support padding.</t>

<t>DTLS has similar record overheads to QUIC, but with a larger increase in size
if a longer sequence number is needed. If that turns out to be a problem, there
are alternative designs that could be contemplated.</t>

</section>
<section anchor="status-of-dtls-13-maturity" title="Status of DTLS 1.3 Maturity">

<t>DTLS 1.3 is a small delta off of TLS 1.3. In Singapore there were no
remaining open issues, and a proposal to go to WGLC once we had more
implementation experience, which we are accumulating now, so absent
input from QUIC, I would expect DTLS to go to WGLC on London.
Note that due to the lower level of inspection of DTLS and the
preexisting need for hole-punching (e.g., WebRTC), the last minute
middlebox interop issues that delayed TLS 1.3 should not be an issue
for DTLS.</t>

<t>However, conveniently this status allows us to get the small changes
described in <xref target="dtls-changes"/> in before we close the document. The TLS
WG is very interested in coordinating with QUIC – and has many of the
same key players – so it should be possible to close these quickly
and proceed to DTLS 1.3 WGLC.</t>

<t>In general, DTLS 1.2 is reasonably widely implemented, though not as
widely implemented as TLS. All the major browser stacks already have
it to support WebRTC. DTLS 1.3 is less widely supported: NSS has an
implementation and I am aware of several in progress
implementations. Presumably, stacks will need to update to DTLS 1.3 in
order to support WebRTC as well. Having done the DTLS implementations
for NSS and Minq, I can report that it’s not a huge amount of work
once you have TLS 1.3 support.</t>

<t>One important note here is that unlike the current design, which is
very tightly coupled to TLS 1.3, the design proposed here does not
depend on DTLS version. Thus, it is possible to have interop with two
stacks as long as they support a common version, including DTLS 1.2,
though of course 0-RTT will not be available unless you have TLS 1.3</t>

</section>
<section anchor="epoch-and-acks" title="Epoch and ACKs">

<t>DTLS record sequence numbers consist of a 16-bit epoch and 48-bit
sequence number pair, with sequence numbers restarting at zero after
each epoch change. This would put some stress on the ACK format,
but it’s easily addressed by having a separate set of
ACK blocks for each epoch.</t>

</section>
<section anchor="crypto-layer-agility" title="Crypto Layer Agility">

<t>One concern I’ve heard raised is how this affects the ability to swap
out the crypto layer. There are pluses and minuses here. The architecture
described here is a better fit for swapping in a conventional channel security
protocol (e.g., IPsec, etc.) because the layering is very conventional. It is
also probably better for swapping in a protocol which has totally out of band key
management where you just carry a session identifier in the packets.</t>

<t>It is is less good for swapping in a simple crypto core (e.g., OPTLS),
because those cores don’t have their own framing, reliability layers.
It’s not that onerous to invent one, but you do have to do that. On
the other hand, those protocols often also don’t have other protocol
engineering pieces (e.g., cipher suite and curve negotiation, so they
are hard to extend).  Another possibility in that case is to move the
crypto core into DTLS. For instance we have been looking at adding an
OPTLS-style semi-static mode to D/TLS.  This has the advantages that
you don’t need to reinvent the protocol engineering pieces of TLS
while giving you crypto core flexibility. See <xref target="I-D.putman-tls13-preshared-dh"/>
for an example here.</t>

</section>
</section>
<section anchor="webrtc-binding" title="WebRTC Binding">

<t>There has been some initial discussion about doing WebRTC with QUIC.
This actually slots in quite naturally with a DTLS design. There are
two primary structures for WebRTC with QUIC:</t>

<t><list style="symbols">
  <t>Replace SCTP with QUIC but continue to carry media over RTP</t>
  <t>Replace everything with QUIC</t>
</list></t>

<t>The former is a trivial change: you just do a DTLS handshake
but signal (in ALPN or the SDP) that you are doing QUIC instead
of SCTP, and carry QUIC over DTLS as expected, using the same
DTLS Exporter to generate the SRTP keys.</t>

<t>In the second case, you just carry QUIC over DTLS, with whatever
media over QUIC binding we invent, and then don’t do a DTLS exporter.</t>

</section>
<section anchor="implementation-status" title="Implementation Status">

<t>I have implemented the core of this proposal in Minq based on the
in-progress implementation of DTLS 1.3 for Mint. Handshakes succeed
and I can exchange data. I have not yet implemented 0-RTT or
resumption (though Mint supports both) and I expect them to be
straightforward. The one thing that seems like it might be slightly is
exposing the DTLS packet numbers to Minq, but that seems like it’s
just plumbing. The whole effort took me less than 12 hours and
resulted in a net shrinkage of Minq by about 10% (700 lines of code)
just from code which was obviously unneeded and in the way, without
any attempt to do a real scrub.</t>

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

<t>No doubt plenty.</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="I-D.ietf-quic-transport">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>

<author initials='J' surname='Iyengar' fullname='Jana Iyengar'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='March' day='4' year='2018' />

<abstract><t>This document defines the core of the QUIC transport protocol.  This document describes connection establishment, packet format, multiplexing and reliability.  Accompanying documents describe the cryptographic handshake and loss detection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-transport-10' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-10.txt' />
</reference>



<reference anchor="I-D.ietf-quic-tls">
<front>
<title>Using Transport Layer Security (TLS) to Secure QUIC</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<author initials='S' surname='Turner' fullname='Sean Turner'>
    <organization />
</author>

<date month='March' day='4' year='2018' />

<abstract><t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.  Note to Readers  Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1].  Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-tls [3].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-tls-10' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-tls-10.txt' />
</reference>



<reference anchor="I-D.ietf-tls-tls13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='4' year='2018' />

<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></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-26' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-26.txt' />
</reference>



<reference anchor="I-D.ietf-tls-dtls13">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
    <organization />
</author>

<date month='March' day='4' year='2018' />

<abstract><t>This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol.  DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.  The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-dtls13-26' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-26.txt' />
</reference>



<reference anchor="I-D.ietf-tls-dtls-connection-id">
<front>
<title>The Datagram Transport Layer Security (DTLS) Connection Identifier</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<author initials='T' surname='Gondrom' fullname='Tobias Gondrom'>
    <organization />
</author>

<date month='December' day='27' year='2017' />

<abstract><t>This document specifies the "Connection ID" concept for the Datagram Transport Layer Security (DTLS) protocol, version 1.2 and version 1.3.  A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-dtls-connection-id-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-connection-id-00.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.putman-tls13-preshared-dh">
<front>
<title>Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs for (Datagram) Transport Layer Security ((D)TLS) Protocol version 1.3</title>

<author initials='T' surname='Putman' fullname='Tony Putman'>
    <organization />
</author>

<date month='January' day='31' year='2018' />

<abstract><t>This document defines an authenticated key agreement method for the Transport Layer Security (TLS) protocol version 1.3.  The authentication method requires that the server (and optionally client) is pre-provisioned with a unique long-term static asymmetric Finite Field Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) keypair; the peer must be able to obtain the public key of the endpoint via an out-of-band mechanism (e.g. pre-provisioning).  The handshake provides ephemeral (EC)DH keys, and a common key schedule is agreed using Double- or Triple-(EC)DH.  Confirmation of knowledge of the key schedule provides server (and optionally client) authentication.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-putman-tls13-preshared-dh-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-putman-tls13-preshared-dh-00.txt' />
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAMPMnVoAA+V9fZPbRvLe//MpJnalvPs7ktrV+V4sn53Ikmxt2ZYUrXyq
lMpxDYEhFycQoDHAUjxZ+ezpp7tnMCApW75KpS7J1p2lJYF56enXp7tH8/nc
9FVf+3v2v/1w9cC2t76zD198d23cctn5W/n4Dn9StkXjNvRk2blVP+98KNqu
dvOfh6qY48V52ddhfnFhCtf7ddvt79mqWbXGVNvunu27IfR3Ly4+u7hrXOfd
PfuNb3znarNru9frrh22uoiX9HvVrO03+My89nt6oLxnr5red43v5w8xvzGh
d035k6vbhta098Fsq3v2Vd8WMxvaru/8KtDf9hv85Udj3NDftN09Y+fG0k/V
hHv20cI+123wh7K/R11VTD9vu7Vrqn+6vmqbe/b5i6+/n9FyigV/6Teuqu9Z
/7r7r12/2iyKdmNM03YbevzW04T2+dcP7l5efnbPmPl8bt0y9J0raAe826qZ
L2kjtuj2275dd257Q9M3RMC+4gkt/Y/e8G5jL+gpT8QN1tlm2CzpsNqVbcvS
+HLtbeGCDwv74qYKlk5r2Pimt0XbhKr0Hb3TWFeDhrwwW/pQrRua3+5oxhum
vaGVNWFL5LM0Rjc0tqw6X/T1fmSNme1vhmCD37qORqKD6m/8dPkmX/6qazf8
yDj2tvKFXwg5NlVZ1t6Yj3HAXVsOBd5S4rx9+5+u5g8Xle9XwmdpjHfvTnxZ
B/rYBVsMXUd7r/dGNulLu/Xdis4k/Aqdl3vaVFNiR7RNe7n4o8mnAHPT/y//
SHPQMlYrej1RpxrPaGH1BIS+OxcMdk/yMtQ9zgtfdEy31t44Oom+Wt/goIZt
jY+Xvt9534BmZrraG2KUcONeewuOmdIUn9y4CWcYV966pndrYpgK4zk6Vnqy
rttd4Nd1n3ZFn2A5PY8d38IQOIZPQjZP8N1tVXiSLRqSWKCviqF2He2vrtyy
9mBokldaQEmfENPsZ+b5ixfWh77aMKFn1vfFwj5ud56+nsmSQqsU4qUGfONq
OzTb2rtAyzEkjaQuhMdJkv6DiHzAdRl59CzoFMKw/AcdETbn7K3r6Cj3KjTE
3zXtgwQ0DMT/Ltxjef4Pex2ljd4fGt/wLMRDRD4QbenXVdPgpGgc5v22aXwh
W1sOPY9CemF8b0VSx0+OKyQtQVsjUV6cmLRp+3zhfDo0CYlH/TnIVZAo+zeF
p7HralP1kO1Sp123fNr0GvG2SDopjRJE/pBlPPd81JsqBNY9q1H3rDpSj0Hk
uW4DibErXnuavKGFEKW3vqhIncsyMEWtTO5u24qoUBSkh4ixapIXJY5qj80R
EdrVKmBoshTgC5+vHhxIf4Wsgt2x4r2uZaGzswBGXakLG5fE525JHchwPOdC
OYrVDpmW4rVu60A4d1V/k0RHnqMdvm7a3QwjGrYsZJkKPyO96unJ7uDxAK18
/ZiMin38/PkMf9KDtE/mrXZoSnBpoJGw+agMVjXWQdr92tPIVyEM3n58efHZ
p7wP5geHoxSepN2TCQVL0K/briW5jDukMTEuH3wFS61yQHapHXq1BfFkwWj3
H3xrW96HfgqJIUWzpA9tQeLZ9f6N6J+i2tJz/Cu9Jae3bYmTaP5I4Apm3BW9
cpecAC3DblxxUzWqfgrQ+kwWsyFGDTIT6zCaPq6P1SepYE9sXp7zGnhinH7b
rIZAwyzs10Sh8VQq2DaMoQvD+RGLbVuo1BakvGqqHgwjs0CkWSJBiKpf8C4C
Wf2GVF8QEjPFsduh4XX+Fq1xZjeicpkrvb2YQ0meYQdeGZbMl9XPV+RiDLTI
80jFCYe2rByqZuC9qIIe5ZYYwa8q2pNnQ4UVs36mZ0lB4GCf+N21Z4F/UfGW
Sc4DzAamY4kggWN9kNvLKjSf0LmTX+VBCmwPrpcQmEhK6grnfOt5I5PnbDl0
0XOAZCSFRE7Be92XaFFVDQtPkhJIbERkIy9zMzPCNxWTpnZ7eow3MRqx5Myc
tPJlNPNnLO2h3dDgGzoQcVwCJowK4Vz8LRPXVpZ0TGSi7AYaMhmI0XZhF0VX
LWEXlrSOGZyym3ZY04J7crJFe7Mj5GXqxu9oLyTwQaVzQ540KYZEG18S2ciB
eihreHoLDvA7kNJHX0gceewYArju5AjBIiRG+Jhdhw1NS86YTLNmBUyqnvcB
KxNtv9gAjLiwVwu/mPFCSQiatamr157lgYz0/6Qf1cgHP3+Yy0/68/Rjv1he
G/15f7vF7+99TP986Hqnj8Whx5+Tk9K7T5mTvhbzpqOJJQrW/uZo84PR8p9H
DXF/u/X5Wk+PdjT6idGs/eHhs4Odf+hofBRv79mPV9VavGXX0Rlz8PfFRw8y
JrH36QtSFkVPGuejdyqQKfAw5Og5keqJYsv0+gzMFEi/NeJ2etJ38DnBHmXl
iPk2wkFv355w4Bcj30w29oeTR3/01BHdfpEv7OPk9MgHX06fOn7vb/TS311d
lbBO90Ww8e5vvUevPf32zqOua7s76f0Pm+/UOt8zHx9Vvr9sqmx/LD6n53sf
PT9snXM1TU+//fV1Hr93+S+8l1HlIQX89vR7/yq/ZBP+j/e9lb7/Rd941rUQ
kvFvJASnfn7RN26zT56JZ/Gen19+z2745469c8wXH/bCuJRf4lz2G/rg2pPI
9/GMPonP615hPOKB0gvTh/mF4x2c0EGZ0ghRFyVDdZV9CT1krkSZqKklt5Zc
OCI6xe197jOQ4+3FM4RBI/+rcaTKKDJhV4BeIM9oYO1GdovCJ0SviH0RHpOh
e/zixbO74iHQKtTAqU56v6b9g8nonc5Az/ND33sYpfV3vndgFz78vauJOfn1
945Pj/E+mJE+P7vMuXIHluQp+01dIMLv24HOoSKfCk6s+lh0rG4CgfB48IkZ
eDLwxKv+k0BOXbeGAdLo+xaOZUvvZkPwcbpmb91WbBRQJeKZvi3aOh2vuNAU
VcHlXtFj5HUzunCFafIQAeGmLeFenJFRE91HXjwrs3P1yse4mgMQCa3pu8cx
EjhCyoCgkNtBjB50DIpmyD2PIA7vgj7QACUIjrEm89uIM8qAEq1qId5e2xBV
yFTXKeqlsLvdkF8nDh+2C2MtUYPrOqahOXCPx0XN1OXEcbmaBi73aQxFqNR1
UKk8y7zZTxTJgCdAfvJ/pzE2bs9gj9lR+IQ1+DcQYj5fejwDijwvkUHJs+A9
+Qpd389HFOndu3OOzFj0FTNp4J0Hh00JtGacXVFIFpljH3rEwebp1osDjOOe
pSGAyyLKpuhs57pSVhwjHq8sLcBbY5gfmG6Ki2RsT0vfk9OXcR6f0egXGSLe
27cQpMs5bWvi9Fj7oK5A0Q//uWZExOjbj+17pfi9P1/Ku3/77SfjDyCMxYKC
66snv+td+yqn2o/yLg3y+xf9/jXbV/kUp0b+cqrO+BSiEruuGEiZ6jJxhD2J
xr5uHcec3gE1PDhj4QAVYg7QQm/o4ZxTaleVHLiC/xsKmrf0fBWg0BzDnypT
IpaKdSzsV75wQ4h8eDgvAIh65/bBJOBROXvjHazrjcbN+UqAvdG8t57RC8Mw
bHqdePIlcbrqOmChQcds1oJ20GqhGEiGScfPOH3CStn1+SwGKNLSC/ClAYF3
HT05FQqbhOJChcJerdLsFHf8g52sGcufhBWyC4z/D42JOaJFbB0EowQw2kVM
s9fXWT9h5YDG3JJWEtVR2TKCsdn4EjKPE2nEOtEuaMccekPVYCpS9A1DDF7V
EKnZarXHyB3Ofg1txdkbGurfRMJ/UzJ+n6S97+f/Ke1wkWuHAxeHESLmUXZR
P/7YPudESFVX/R6/fyzPZZ8mmFI92pQrmsmjveCdYDfFXSAcXTaAQtdm9DcY
OMTHZE37+fh5BPLO7W3lyHMg6+kB807EQqD+UJAyAD7aFPXAWTCscSFrEjiX
dM5eXIy+zSYXbRdUVOBT47myZXiQ31FLHgXWcRJqYQ6HpscYVc5SJzRknoI5
mpSRL1CdlMSj5ByQiacg8bbq+sEnEC45KlVA3lNVItTAGvmFZuJ9mJS25IVn
0qyJmIhXd3IcEZEWt5N0KWu7DOYcV769ccEv7BMnIAoWsGuHuoTCEuhMPF3R
8+Q8c8YEPp+oW0dqC1kfpHbichMITcdsTrHMxhe0gipsQmI/8npbXprGR6LZ
jWhBBq/FTZQc5Y0aHjaOCLPU9vgO63BNnuTzY9L34QTeHT9fVR1p0g7pDtN3
1RbKnw2qpFQxdHS1oKVvq9IDWO7bdCYGyccshVC8ZgwTZkTg+7iYyCJ8kKfl
8Ku9HKsLZMYEBANXMqsn1jwyucqCRvMUGMFhG4lbM56X5ARkmi0Vcwd0h9kR
wyDbOeFRpprftoxiL4Sbw7AkBUTLjkezm1h0EaMCmaga1QAzMlHsLxiKhhsy
UuDgTg5z6ldgcHIcQMoxawdeYq40S5+YQBMiEpsEgYxvKCbwnF/BER36RCYj
FKkWhNIRF36lyMMTHu1H+4oB2PQnrIf+VZ43KWEsi6Oz4uSeQ1InICyiqBE5
QpoemYeYAGB6d35F5lO5J3fRZC9aNFFJVhzihSAiBViSQ7it2lo2VU3Udsqt
p7MQbtyl6BZ6jWRkJyoddSD2JbPM8UpSdMdsY3fgBihsmvWDXyrwnwqFIwre
wjck1U/B8JJkaFgj6OFYmjM4OYrbt6OAi9zYv2vq58mY+mHDlScWJJ4fQ6V+
18aUUeDtptRqTCQt92CpVD0i/pBCOsjU62OS104On6Z+OSAuUCqARcroIEp8
K+V/0orKkxMiCxinpLOC3oyrHrXPJOVc87Rt46NzvIMlknzaFKxAvqpaEddl
wXEVhDmJwVgv8UmmYhWL5A8ORBUIzyye4mNf1y1zebtcDSHKFpJFcEZzf5Wk
HlgK9CByRjNeEbKfJKdYLZxlDo3Z0k7WPG4+o5s67AVJUctSQapiZsTVv3fi
8AIfPifvSXImTDCdgwb+KAxbAA6+/Cl+/BE9lzOKPAe4aXzEnjV+d27M/RNH
VNy0vAic5Zalnqjp2UTzhsVeAAS4T+TZJKRo51MMkCdTWe2N5iuj/gx6dSLi
6v2LD9dKmY3oiTOGIUtP5qHWRLsR0AERD8No2cjv3p3PRvbTI3NlKxyRABfx
18QBdZqfRKEE7ZBXoho4JAmJbpraqSgKGYfxrBJq8O8kH9Goucnpqb4k+opA
YJwofDQ/1wtaEkNIVrYzDoh7IrOEjzQs2Sde39UqP0SsdN1U//TqT+nQGvmR
ChMXk6YoPYtKOHCxotvLG2IxyVdP7+V57OQaWQWa4PPfNvMwFICT6DhOLDHK
alrqwUqrXgpUkPm2f38STSeZTD6wXHnaM3ASe4CRlVwpak8sGNZ+LnUHKmtM
h87PpQbm4BTpTRQHEbtE0tOgyiajSkon+aTtfayrgBYfgnh7AVYkG3ZxLKyq
ngNXTbgeVo/T3I0oJdpzPyF8TnZ6b0puhCN7Ifb/zkg5Tv2Fvf/qxA7o45n9
amYfZIHge0JHxLTjaF/Z4+Hw8Y/T2HHkoxhA/v1EKYXwBNlh+hV4cyYzHFb+
W9LjRGRNjJ6N9IrHOTHzV/+HTuLoKJjHfvMgKAJ+71EkaZl6gEGzmit4pQzb
R7M5QcerxkgRyFjxpfoEpZtQQ2uYXM49sPFCuipJ6lVjpk4XryMrm4SmEc/u
cHiSSaOO8MZrZoH2VpejSp5FZWr7ZCzEDpFlR62hYeLk1HLABCk8VU/xRUog
PBuzGia5fqfyC1axwanDIeHPm943zBrGsY7bZ64SmQ+d9Fv6/AETTrT9E7+z
WsxkpZqJwjtFTg/hTy7Ocl1X0bST+maNEdiPNxoeS2JFYY5dV/XRqkS7GkN/
dsk4t4Jw+ihqPJPwoqr3o8E6Z8NAWlYNK0O2hgd8D6ATa1ax/x+2nPfX3U8q
ueTQUWFv0zbEa9v6VEMJhyhVFGcbB2sMESae6fk5PYEsEpfHM0vCsmEqicY3
CN85oBAaH4vFbCxCT8moXylw2zpSpkzKJQf9gnyhLLM101LLNq/KBqMUyihM
FS529mQPyUohS9aVCn+MZCAXCwVRymoPUp2vvXpInB0LyFh4KcTWwnpVRuxz
FpNXNOpSZ5zeMivXbVjiOcjj5J4W1nvps7CnitPm47DzqkT26AWoLi8IfEjj
cMUowopk85Hg6v16P9ZvJcpLOIAYPiS8ZVrbTBtINbPMPLRaFirJjSrhNllh
907LH5PUxoI1uJ5jzgOcbFwWTItTBOfgpu+34d6dO2vSPMMSrRV3EArs1neW
pEbnvOFwR4rj7lxe/PWzc5NYCYp2ZjcQEwWJYkU+u1olhStSJ72tXeE1f9qh
m6MppbFiUlVAshaFQcIFLvdEgSl9s6cArO+qwhyet9PnaTObYLU2zmcglw60
bmkgqR7nWSO2JZBb0FT5wCuTospUDSmga8Gb2sIYbJDRAGwjYYB4lJEptZ5f
0t4oGnzuiaIwM1GJqsNp334srCYfk+m7RlxJY3qSnShIQktW4JwUBoPEAIi0
94ACYNJ1/T4VTk9MmG6CfVtipemonQd7pUMjFaZ1HSZmokuUAmFKLkVkVII8
50pKG0WO/ZsqcJl5EtbCbQUArHyK8qdszh1Js2nhWlobK3jeLNcJjHVJT7PY
8GRUR09nz+R4yqnn5zCJ/NIEJ7OPtHI+e2srg18jzVTD03yOivn0NdfPv5P8
ZYiRhgB1ZQnoCH1YVTESZp94QMsP9IyR/zPLfawG11oKZqOPTxMiMlFOB0Te
MJFjASxPlcAM8LCoi/fgIOYgSh1t4ll/LMJ5MMgxpxHMwrvuPNNV2JL/hC0W
0XANKACY6FigLbg8cpXDGqkAgZS+RwMMORo37SbgRPLKY6669spGaAczKtDP
aofCpzccDi49uCu6rUHrUNCYhmKUCG6jKaA0k5fz+lqpaLJvx/JYslXkPvUv
UIeAYoTPx6+e6cFF/1fnzp4YaIbLPysA/YW9+M0g484dOUTSNnU5HefTv5Ly
+3kACvOToJWf/0vj0Hpq36z7m2yd7dbRyPDm1lDRryb0WcjjP+rz76ak/1xB
5ZcCr8SclS9qqdOBjkeQPR0yHhM0smd7DY3SdkY5eecz647mvw89ItnJT1w2
8sXoF34OijxHOc+DFxFiZ62WlMDvOVYlVxn6n6DvfqrKv10sFnf/9Kcvj54J
XXH4zP+9/JESMj+Jq/7qFGck/fUgNbFEHmGXXER4NHhQhpIgik5RzDtNu/S4
BK2mAQPKxUiVk2Pci87lIqczTopoDUcjNA32YmYvJfi6ey4NLELsCySb8mVs
ky6BGhITdz5jHZcDb+zINMgXQrdyc0nCoiSWlGUoTPTtw6/ReDviRlvfZU5n
KqpK9pN4yj64eihLhd7S7gzezcxwlYhqc/a9tXJEtsFzJPvct6XbL1Kk7ZP/
WngJa9l5jU/nkUPwKQ27ptAHwvRFOoyom1MDl2ZQokiT6awRzo6pHNqPQccg
bIFgtYJWHkAA9L+cqgk6S1Wmsmra8RW3KnFfaipe5e6t5D9iTtjT+82kC/MQ
a4idnNrvqenbjxAOoXDNZPAF/LWPRrdMcAeQHlovxsTAAdREVSv+VpL3SCaO
aUaJGMWPJL6d1F0+RMUu+ZxIsbSdVObpULESl8RjM2xGetOwZG9Ff4onYOK6
kI/PuJcI8urV02ePntir6+sfHt2z35D7p0sXUSZTjB7GH3+UQO09blb0pI6d
EnG2UoVxIaPrvhVzjZkFWl8uWQrDp6czfNjAnWGfnS04mwdGeB37FqkBUd7g
NjRSV5COLGbLEz4y1yLL6hHt23U7hEk4fiJjp4KhAWjPiit1aUuEjw1Wku/M
aZ/KzqStK0WnMZM/6fVWjytP4MxiwyoCEgRjHJbSfncef1kkE8w5EiIJe7Cp
sRrGtP71rSlVLGJgQ07aNGMnTaJ1Jd1YCSic5Jc4AoyLF0oZLfT7dzDhMLH/
P5tx/fwYM/7bXezp0y8nhjwT/oxLoi3/oUlB+CEIJbox61PMHfNp46MpKKZF
tTinedtds+4cnaukQMQrYKE5ys0cZtiAWcGKpw6SozzNsa4ZRTL/LsZPxgmi
1Wuv7Zqj78jbsf49304fC0oAYWUJqCTqOUlg/Flvwey9kaBYAkBVro+lHmQM
U6O63SL0m4Z60SXgZG1eWyKeE6pRj8NCwwYlMlt8Ye22qVhdG4axNo7cJ5gM
d2lvu+rWFXvNlULl3rp6YB0iYWADZeyCADQcAHMxW+k0CcsWno7spql+5sZM
7Tgpq1AMAYZdoKEITswkmth5s+ZiUSRGG1fVaIUl9lmQ6PseZVqM6sa4j+s4
pPMzVSHFKnSBSbFcIf9B9B+pLsH/ccx9lHLUaDWkYfhNyTouQSEyWVobFt2e
8S3HTaoJsYdOfZSqoB6NQH5kHS5lUC/mE3hdfHMEvm3IGEt50tBxOcFC2jN3
VfBGonnO1hYpdcCXCkAWow08ATAh7L9WHvjL4rPFpzj5o+7D8W4R6ac9BY3x
oA8VEwzGPF2SwzMEVNQkknbyXoKMDqEoWRhjl5B/sGssuOpegxVifoCJQ66T
47omWnLnNy1xqmYJguyI3D1oKZ4DHlsTJxbGAL/EBR92V1chlkfRuB5F6T0t
vN4vLBll8QGZPypupTEw0Sn1jzeC+Pp0bFLQHTlXelxGmHlmpAolvzCEObzd
+J1gTKg6emMp6Eiou8Q/tXe3XM8RE0NHyaZxc98nsHcC3EKP8LUYjnj4RK/P
S8FgV+QGx6IIIYRVGdMKtzw1oB+eaQYcXgpDwbFdOvTDahWLZziBFsI5uH7p
gkwtpFtZ5Usa5U/2TJUoHAoBJ79mtxzlgzuOini10rgjxV49P3rqmh6aLPL8
n+2ZtjfLevkXmeUcIr+nGI2GfpRHh5PV2b/Ys++qFTtJLkuEnEPjkW6i4w8z
HZy5g10q7c1TklFsw1uCqjhlVsW6oeZEU3LHmcBYMqCvz7PXUTkAZSU1K1Hh
b6rY6p7hyBL3IuEyKZRJSgmlKzG+7lC00/iS2EZaBSHpLQxP2lc2HV8sQcqS
1FkVbtBsoMmsfT3BmAsu9Q03OZggwbdUu2kBRxVvYJnoZCbiWbuNDUzniLTi
auh9qVYsPa5bcdIxtoScLKPXQE+3LWmVBoDXdmzojLdM4BaVF2l3WOpPZDtQ
27Tj/hQ6jVJaLIYmXfvDAh7EmSBFjnPgJTOqzPipa2L2gcdkZj40S1zFCoY8
GVNL+HJQd4UDZ30X3eq2FElcSr2w4rfi5apm5MTMeBEDX4rx9i1bgaxoek5v
zoHY4FYp2t7btzxI9jHvIYrIZ1F89aYwfierNz6f2csLe6Y3C2iN1+UlCmG+
RqnYAyksPxeFxUSIG1fB/4R2HavUerIS7DvIttFtLsWwNIMu6PLuOYc+fU/7
J2rQTJEHdpOxxq4iAaoYlIiajIfWa8VoBHGutAmI+KsiXluOISLf9RNiTgU3
sIgPxd4RGSfUQ+lFM3o5jrZWOhEV2QjPnxa00L4KtnP7TN/fr/mWDXLW0rlq
5VOMrfOrbaa9AxhKBr5qFOUJ2dAvTxf3iVednscXrhf0SXN16Usp4hf1XzVF
ta01BZFcuwieiS25ox6wADHSkCU+KHcoaaeyKqkqZNrjsG+RnZdnbS/yg6sL
KoVpvvINOWzwW5SgHTk3LRE5FHCmpdCcaFkjBvMpF3vDeQo/XiGm/ZZ5f6zE
0P2unXStRQvI+0WXMnBOXACxmN7RpHcUcWFMg4yMydoiOGCLfQi7No09FtpL
YnQMmsiNCNKB0bdr5rNZgjuxnIMbfnAQ0mcmHWm4kgm6+DJ9Fu8iqrJZz9MB
fl01rO5jqil7msiEiraXEeKc4d6frIz9VNup9kxAijofgUqjHoeyBzsuk+SE
/j7C1/rB9Q0p/+xTznNL+wWIKZFhUAldDlXdz+nQFFfjCF3udnJNptyXipOU
Atuwcge+zBUMJ85Z75yDWHKqxZtttV7vgVjqRWqxigb9zOkc2bmhCGB0splo
QgrjEd95KSdIScpJTjjiXdqIHC+pQRwm4ZpUckMavsc+rqdHYR/6zfAGVSHQ
B1oLXIo/Aguo0Z6UQoqOkUudSrwnssOMJGg46JKypjFW5evFlujcHgXlT/N+
AI3OVHOwEcSeXvrl8xcPzkcEYBJXSGmZJsdNVOqzVIt00NJq20jWUalHlX6o
Q561VSMV3Q/g/HRNrkGuq3/6O7h1COeiOkSeguaXHTLxqkgmxd5bfWch7fZs
sulgOtG4nEFJ0jEftlIh2VUIy0/eEMC3OS1H0sjGMn7iGo5tnx1YhiG3KyPI
4RRZYBFYHHkqKV8xuW8y4fosviRe49xT+ZXAWptyFJ2B8hRI/y8MaMdXFBP6
4wW7NIfrY6hE92B0sRg7QO4Rt2gfE1bDMHkc7/LuZDyTjYd+oUwBoPQwVVZk
W0cFk2O55+XybR4wM4XAotIFLypELIf0EMNpK4VnB9Kbx41VHDeO5po/c82k
jmWL5TTrhUJKIFu8y+OAuVLYrt6jbJ5vkEBQV0guAZdOEhsj/+HisRxSugpa
+bGQYnAg/kNHrKS1W+jxiZZMKwoMt0kf3boaDiormGCkFl2vd3kJnjOEVAME
cn+PRA+3laaPuLNHav9LXxOZWoo66R39ng/umujktqKmgfTtPNcoGimUYPW7
9douIkGcbIMYWUCVNWBK+/Kb7x5I5LMTNQjNbw7aAdEKTrGbXn/I+TYJrl1B
ntVQC6jKtyWianwJG22qZksEHMECexWLVLixPBUUTdZhv2ubErmhMR1XSn0g
izQZWaQSbj1HsVXDl8Nl7QnRdpPE+qRA2dmTu/lqP98OTcHW4swv1otZVL6S
X6gd2c9N1Qy9N3KF7bJ9IxKAujIB7WRVHgFZmTKW6rdpE3ns0zExRbfIGt0k
xVZpwSU7fcIVak4l7yOIYryiTj1hk0c3sRIo1nK9w2dLtuSMb2rjqU+YySK2
VJmX34DH2O/mzUnlC+4oaLlgUg405ZEtLjjWm2g5wBTVJngpwJ0tR6e4R0uv
Chzd2NybTEui/yIse026NStFTkAoCAqGkOIvyarXSUPdFSwi+dA7iogBq0We
zW4DwHGQNjt+Avqd7wG6r9jWxv0DzUQdHQB0BBD/ZHSlPE3izqiphG0WNpdZ
jox1rpTWuGefXIsmc82hXGHvV9ZtUhNhuiK34v7YNS4nO3gpMKqs9YCzuNJJ
VDNI5XBOTYqF0/WQ0y2MNcqPpZGOXa0x8plOzgyNDWHp31fNzxBrOJGd5zFH
9JdJb28G8pvdph0ajjqB0xjWNimHnARIVqVtsTQt/YJAFuZ57FvG8MOvJXvE
QTfM2r2WyvKtjkIanW2WV46O1h2zpIxL6bd8DWVz1CM1BL1vdMLc4gupqpCY
hCx/5KTA5sfGmvd4Bs7yPT5NlldNjfqR3VH3wdzcxouWNKyRQ1eNc+vITGIp
RB7w4SGB2fw8Yrhk7JDOm04P7GKI95wIOHj55zncCp8G+PSv+MAcWtOtqzot
ODkaEGqGK+vWuCvgn0Qouf/XcNliDuVofCH2AmZEbpLq+bI+9alxcau4XdkV
UvBzAXPqhZ15g2hWgy0NdQYjLOsW5wO2HlchCMIDgbu/Y+Dt/lrvfsj94KtP
btmdI+qROxvkCqab2B8oKTtBTbISzLBzWxOdVIXUWX0usstlt/UQFCuGOcLf
OSnEGjy/gCuzCFFIUsv0qhLIBDNuQQJuJplUeIDcjUeLYSFOSMolqnm8ekZf
yd3e5zZzwmXJPKgaknxcuP4QQ8a80nUscVlHS0qTivyyl93KldLcJb2yfJk+
WRpD5odCcc4AjFUvnO0Q+BynLG0ikkFaVewPZjUASKBcSe2Pqux125YnViUh
bTyiAmZVifL0GXr3ZllQAruGJ4LmV+LtClXHdzYA1OdS8PzyBrGZC3MV1aXc
VUfGTks/KiYoPhEnV0p4dGzN2bkerf5SGcbh6A3XpMiKxrC0JTlrYu41LXBa
8juJvPVOXN2wXAFNWqvSjhTilluf4/yKYNEJgX1jtCcxNUW29n6jk7HGFALE
DnsuzJHMI9JP7FrkVOccDXtRk0ufEwDJIFbdtq9Vs0gQAXvLBzUXoD74TTWH
p1UVnB5m+3iHRxVtI9hMdlO+2BszVk5FA9t5PZpJ9v0E+cRnx827tIB1xXqI
y6Gy3a1q8lSFInwPOLl1/wUpTFJ7xOzyjxPMkScnovpyXt68e2cObgeP+eJo
0r+q+B88YFCIT0OBPtaisaBxhDk0aC7RrRCHSL7fQpKL6caSULcCAP7MzDC2
UWkIJrUAYwOAKDTDCJ/ewJBq6EIGf4wzMgj2XHJN9vrBi2eZIwoxyLuGROi5
T14gkOcvnmVvw5vaKzgUx1CojCyHBH8OoPtt5aKTfW9UKWUbN5TCVjY1ch8h
Xxl4/7tnT6zC0tcPn53bdP2MY2ciATRaQYxqcexppvAbln94v2LQEAmOrBQc
RAxJDPajN1sBAThMkJJTWQDtnlHSRSp6I+3d8kTxesZMV07nVasdby4xGVGF
9MJUUg19yzdypnZ2EY+RXF5XKIDT1dTrlRiYVqguU+aVS4KhG6sjU8BKpIa7
iUQrV+iykqiaefSSD2+wySNsMBm93C/GdgbutOP2R/HB9d9ekIwT37xor2J2
g47T95NlxnsiDTviktE7UycNE431lOi/Olc/X+PeHn15jCuYI4wYnCnud7rC
IOsxqvoRWEx9YGRl+bbFyCa864MrXWg28dUld3E46idBGgrJ6dgs+W59rGOH
cBmddOzXk3YlMRN7ybjw5V3ydIYu6KVT6FaVEBJVIwgASQ++1kJXObm96pnL
i/9sz/5ycUHTN/Ha9dKfyxoYL8DvEWggaRgRzaHRjiQtPMCGcXNFTP0arsvu
gbrEi9+cXpxZdMMS7Hitng4gT25b08Dmi9M/KAymYYYlyEOnj+wS/ws3ALnp
r/8LC4ZtgWxpAAA=

-->

</rfc>

