<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-boucadair-dots-earlydata-00"
     ipr="trust200902">
  <front>
    <title abbrev="DOTS Early Data">Using Early Data in DOTS</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="McAfee">McAfee, Inc.</organization>

      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560071</code>

          <country>India</country>
        </postal>

        <email>TirumaleswarReddy_Konda@McAfee.com</email>
      </address>
    </author>

    <date day="29" month="January" year="2019" />

    <abstract>
      <t>This document discusses to what extent it is safe to send DOTS signal
      channel messages as Early Data in TLS 1.3.</t>

      <t>This document is not intended to be published as an RFC. It is edited
      to help understanding the conclusion about the safeness of using DOTS
      signal channel messages as early data.</t>

      <!--
-->
    </abstract>
  </front>

  <middle>
    <section title="Context">
      <t>Section E.5 of <xref target="RFC8446"></xref> states the
      following:</t>

      <t><list style="empty">
          <t>Replayable 0-RTT data presents a number of security threats to
          TLS- using applications, unless those applications are specifically
          engineered to be safe under replay (minimally, this means
          idempotent, but in many cases may also require other stronger
          conditions, such as constant-time response).</t>

          <t>...</t>
        </list><list style="empty">
          <t>Application protocols MUST NOT use 0-RTT data without a profile
          that defines its use. That profile needs to identify which messages
          or interactions are safe to use with 0-RTT and how to handle the
          situation when the server rejects 0-RTT and falls back to 1-RTT.</t>
        </list></t>

      <t>To that aim, <xref target="I-D.ietf-dots-signal-channel"></xref>
      includes the following:</t>

      <t><list style="empty">
          <t>Section 8 of <xref target="RFC8446"></xref> discusses some
          mechanisms to implement to limit the impact of replay attacks on
          0-RTT data. If the DOTS server accepts 0-RTT, it MUST implement one
          of these mechanisms. A DOTS server can reject 0-RTT by sending a TLS
          HelloRetryRequest. The DOTS signal channel messages sent as early
          data by the DOTS client are idempotent requests. As a reminder,
          Message ID (Section 3 of <xref target="RFC7252"></xref>) is changed
          each time a new CoAP request is sent, and the Token (Section 5.3.1
          of <xref target="RFC7252"></xref>) is randomized in each CoAP
          request. The DOTS server(s) can use Message ID and Token in the DOTS
          signal channel message to detect replay of early data, and accept
          0-RTT data at most once. Furthermore, 'mid' value is monotonically
          increased by the DOTS client for each mitigation request, attackers
          replaying mitigation requests with lower numeric 'mid' values and
          overlapping scopes with mitigation requests having higher numeric
          'mid' values will be rejected systematically by the DOTS server.</t>

          <t>Owing to the aforementioned protections, especially those
          afforded by CoAP deduplication (Section 4.5 of <xref
          target="RFC7252"></xref>) and RFC 8446 anti-replay mechanisms, all
          DOTS signal channel requests are safe to transmit in TLS 1.3 as
          early data.</t>
        </list></t>

      <t>This document is intended to provide more elaboration to motivate the
      above conclusion included in <xref
      target="I-D.ietf-dots-signal-channel"></xref>.</t>
    </section>

    <section title="Reminder">
      <t>DOTS signal channel relies on CoAP methods (GET, PUT, and DELETE)
      that are designed to adhere to the following design (Section 5.1 of
      <xref target="RFC7252"></xref>):</t>

      <t><list style="empty">
          <t>CoAP supports the basic methods of GET, POST, PUT, and DELETE,
          which are easily mapped to HTTP. They have the same properties of
          safe (only retrieval) and idempotent (you can invoke it multiple
          times with the same effects) as HTTP (see Section 9.1 of [RFC2616]).
          The GET method is safe; therefore, it MUST NOT take any other action
          on a resource other than retrieval. The GET, PUT, and DELETE methods
          MUST be performed in such a way that they are idempotent. POST is
          not idempotent, because its effect is determined by the origin
          server and dependent on the target resource; it usually results in a
          new resource being created or the target resource being updated.</t>
        </list></t>

      <t>Note also that Message ID (Section 3 of <xref
      target="RFC7252"></xref>) is changed each time a new CoAP request is
      sent, and the Token (Section 5.3.1 of <xref target="RFC7252"></xref>) is
      randomized in each CoAP request. Message ID is particularly used by a
      CoAP implementation for message deduplication as discussed in Section
      4.5 of <xref target="RFC7252"></xref>.</t>
    </section>

    <section anchor="simple"
             title="Replay the Same Request to the Same DOTS Server">
      <t>This attack assumes that an eavesdropper who can observe the 0-RTT
      data from a DOTS client and then replays the ClientHello and early data
      to the same DOTS server.</t>

      <t>The DOTS server uses Message ID and Token in the DOTS signal channel
      message to detect replay of early data, and accepts 0-RTT data at most
      once.</t>
    </section>

    <section anchor="fork" title="Fork a Request to Multiple Servers">
      <t>This attack assumes that an eavesdropper who can observe the 0-RTT
      data from a DOTS client to a DOTS server and then replays the
      ClientHello and early data to other DOTS servers.</t>

      <t>Obviousily, the replayed message will be discarded if distinct
      credentials are used per DOTS server or if the scope of the request is
      not under the responsibility of a DOTS server.</t>

      <t>As a reminder, the DOTS servers in the same domain have to maintain a
      globally consistant server state to handle the following scenarios:</t>

      <t><list style="symbols">
          <t>DOTS client using different DOTS servers for DOTS signal and data
          channel protocols, synchronization of server state is required to
          detect conflicts between mitigation requests and existing
          accept-lists.</t>

          <t>DOTS clients using different DOTS servers to send mitigation
          requests, synchronization of server state is essential to detect
          conflicting mitigation requests from DOTS clients.</t>

          <t>DOTS client sends mitigation requests with overlapping scopes to
          different DOTS servers, synchronization of server state is essential
          to detect conflicting mitigation request from the DOTS clients.</t>
        </list></t>

      <t>It is recommended to implement RFC 8446 anti-replay mechanisms by
      DOTS servers of a domain to accept 0-RTT data at most once and silently
      discard the duplicate the request. Note that duplicate requests will
      also be discarded due to conflict detection policies described in <xref
      target="I-D.ietf-dots-signal-channel"></xref> (overlapping scopes).</t>

      <t>As a side note, the procedure to select and/or contact DOTS servers
      when multiple servers are configured to a DOTS client is out of scope of
      <xref target="I-D.ietf-dots-signal-channel"></xref>.</t>
    </section>

    <section title="Fork a Request to Multiple Server-Domain Gateways">
      <t>This attack assumes that an eavesdropper who can observe the 0-RTT
      data from a DOTS client to a server-domain DOTS gateway and then replays
      the ClientHello and early data to other server-domain DOTS gateways.</t>

      <t>The ultimate DOTS server (i.e., the server to which the requests are
      relayed by the server-domain gateways) uses then Message ID and Token in
      the DOTS signal channel messages to detect replay of early data, and
      accepts 0-RTT data at most once.</t>
    </section>

    <section title="Fork a Request to Multiple Client-Domain Gateways">
      <t>This attack assumes that an eavesdropper who can observe the 0-RTT
      data from a DOTS client to a client-domain DOTS gateway and then replays
      the ClientHello and early data to other client-domain DOTS gateways.</t>

      <t>If only one DOTS server is configured to all these client-domain
      gateways, then this DOTS server will detect duplicate requests because
      all these requests will expose the same Message ID, and Token.</t>

      <t>If multiple DOTS servers are deployed, then the measures described in
      <xref target="fork"></xref> have to be followed. </t>
    </section>

    <section anchor="block"
             title="Block a Response from a DOTS Server or DOTS Gateway">
      <t>This attack assumes the following:<list style="symbols">
          <t>The DOTS client is provisioned with multiple DOTS servers (or
          DOTS gateways).</t>

          <t>The attacker blocks the response received from the DOTS server
          (or DOTS gateway) for early data.</t>

          <t>In the absence of the response, the DOTS client contacts another
          DOTS server (or DOTS gateway).</t>
        </list></t>

      <t>It is recommended to implement RFC 8446 anti-replay mechanisms by
      DOTS servers of a domain to accept 0-RTT data at most once and silently
      discard the duplicate the request. </t>

      <t>Note that when the new request is received by another DOTS server,
      conflict detection discussed in <xref
      target="I-D.ietf-dots-signal-channel"></xref> will be used. The
      duplicate request will be rejected by the DOTS server because the
      mitigation request has overlapping target with a previous mitigation
      request from the same DOTS client.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The document discusses security considerations related to the use of
      TLS 1.3 0-RTT feature for DOTS signal channel messages.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.8446"?>

      <?rfc include='reference.RFC.7252'?>

      <?rfc include='reference.I-D.ietf-dots-signal-channel'?>
    </references>
  </back>
</rfc>
