Extension for protecting (D)TLS handshakes against Denial of Service
draft-tiloca-tls-dos-handshake-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2017-06-28
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TLS Working Group                                              M. Tiloca
Internet-Draft                                                  L. Seitz
Intended status: Standards Track                            RISE SICS AB
Expires: December 30, 2017                                      M. Hoeve
                                                                    ENCS
                                                           June 28, 2017

  Extension for protecting (D)TLS handshakes against Denial of Service
                   draft-tiloca-tls-dos-handshake-00

Abstract

   This document describes an extension for TLS and DTLS to protect the
   server from Denial of Service attacks against the handshake protocol.
   The extension includes a Message Authentication Code (MAC) over the
   ClientHello message, computed by the Client through key material
   obtained from a Trust Anchor entity.  The server registered at the
   Trust Anchor derives the same key material and checks the MAC to
   determine whether continuing or aborting the handshake.

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 http://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 December 30, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://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

Tiloca, et al.          Expires December 30, 2017               [Page 1]
Internet-Draft (D)TLS extension against Denial of Service      June 2017

   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DoS Protection Extension  . . . . . . . . . . . . . . . . . .   4
     2.1.  Extension Type  . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Extension Data  . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol overview . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Client to Trust Anchor  . . . . . . . . . . . . . . . . . . .   6
   5.  Client to Server  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Server Processing . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Replay Protection . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Session Resumption  . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     9.1.  Renewal of Long-Term Key K_M  . . . . . . . . . . . . . .  10
     9.2.  Rate Limit to Nonce Release . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Servers running TLS [RFC5246][I-D.ietf-tls-tls13] and DTLS
   [RFC6347][I-D.ietf-tls-dtls13] are vulnerable to Denial of Service
   (DoS) attacks during the very first step of the handshake protocol.
   That is, an adversary can repeatedly send ClientHello messages to the
   server and induce it to start performing invalid handshakes.

   DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional
   Cookie exchange as possible solution to mitigate this Denial of
   Service attack.  While this makes the attack more complicated to
   mount, a well determined and resourceful adversary able to spoof
   valid IP addresses can still successfully perform it, by intercepting
   the possible server response including the Cookie and then echoing it
   in the second ClientHello.  This is particularly doable in case the
   handshake is not based on Pre-Shared Key exchange modes.
Show full document text