TLS clients should reject static Diffie-Hellman
draft-dkg-tls-reject-static-dh-01

Document Type Active Internet-Draft (individual)
Last updated 2018-12-04
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html 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                                                           D. Gillmor
Internet-Draft                                                      ACLU
Intended status: Standards Track                        December 5, 2018
Expires: June 8, 2019

            TLS clients should reject static Diffie-Hellman
                   draft-dkg-tls-reject-static-dh-01

Abstract

   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.

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 June 8, 2019.

Copyright Notice

   Copyright (c) 2018 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

Gillmor                   Expires June 8, 2019                  [Page 1]
Internet-Draft        TLS clients reject static DH         December 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Key Words . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problems with static DH . . . . . . . . . . . . . . . . . . .   3
     2.1.  Limited cryptanalysis . . . . . . . . . . . . . . . . . .   3
     2.2.  Lack of forward secrecy . . . . . . . . . . . . . . . . .   3
     2.3.  Confidentiality violation by middleboxes  . . . . . . . .   3
     2.4.  Message tampering by middleboxes  . . . . . . . . . . . .   4
     2.5.  Session resumption by middleboxes . . . . . . . . . . . .   4
     2.6.  Static DH implementations are error-prone . . . . . . . .   4
   3.  Mitigations against static DH . . . . . . . . . . . . . . . .   4
     3.1.  TLS Clients MUST Reject server certificates marked for
           use with static DH  . . . . . . . . . . . . . . . . . . .   5
     3.2.  Client detection and rejection of static DH . . . . . . .   5
     3.3.  Servers MUST avoid accidental DHE share reuse . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
     5.1.  Timing of rejection for detecting DH reuse  . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   TLS 1.3 [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.

   [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.

Gillmor                   Expires June 8, 2019                  [Page 2]
Show full document text