Network Working Group M. Boucadair
Internet-Draft Orange
Intended status: Informational T. Reddy
Expires: August 2, 2019 McAfee
January 29, 2019

Using Early Data in DOTS
draft-boucadair-dots-earlydata-00

Abstract

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

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 2, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Context

Section E.5 of [RFC8446] states the following:

To that aim, [I-D.ietf-dots-signal-channel] includes the following:

This document is intended to provide more elaboration to motivate the above conclusion included in [I-D.ietf-dots-signal-channel].

2. Reminder

DOTS signal channel relies on CoAP methods (GET, PUT, and DELETE) that are designed to adhere to the following design (Section 5.1 of [RFC7252]):

Note also that Message ID (Section 3 of [RFC7252]) is changed each time a new CoAP request is sent, and the Token (Section 5.3.1 of [RFC7252]) 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 [RFC7252].

3. Replay the Same Request to the Same DOTS Server

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.

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.

4. Fork a Request to Multiple Servers

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.

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.

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

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 [I-D.ietf-dots-signal-channel] (overlapping scopes).

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 [I-D.ietf-dots-signal-channel].

5. Fork a Request to Multiple Server-Domain Gateways

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.

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.

6. Fork a Request to Multiple Client-Domain Gateways

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.

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.

If multiple DOTS servers are deployed, then the measures described in Section 4 have to be followed.

7. Block a Response from a DOTS Server or DOTS Gateway

This attack assumes the following:

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 when the new request is received by another DOTS server, conflict detection discussed in [I-D.ietf-dots-signal-channel] 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.

8. Security Considerations

The document discusses security considerations related to the use of TLS 1.3 0-RTT feature for DOTS signal channel messages.

9. IANA Considerations

This document does not require any action from IANA.

10. Normative References

[I-D.ietf-dots-signal-channel] K, R., Boucadair, M., Patil, P., Mortensen, A. and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Internet-Draft draft-ietf-dots-signal-channel-27, January 2019.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

Authors' Addresses

Mohamed Boucadair Orange Rennes, 35000 France EMail: mohamed.boucadair@orange.com
Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India EMail: TirumaleswarReddy_Konda@McAfee.com