<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4419 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4419.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="no"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
     docName="draft-ietf-curdle-ssh-dh-group-exchange-06"
     updates="4419"
     ipr="trust200902">

 <front>

   <title abbrev="Recommended minimum modulus size">
     Increase SSH minimum recommended DH modulus size to 2048 bits
   </title>

   <author fullname="Loganaden Velvindron" initials="L.V."
           surname="Velvindron">
     <organization>Hackers.mu </organization>
     <address>
       <postal>
         <street>88, Avenue De Plevitz</street>
         <city>Roches Brunes</city>
         <region></region>
         <code></code>
         <country>MU</country>
       </postal>
       <phone>+230 59762817</phone>
       <email>logan@hackers.mu</email>
     </address>
   </author>
   <author initials="M. D." surname="Baushke" fullname="Mark D. Baushke">
     <organization>Juniper Networks, Inc.</organization>
     <address>
       <email>mdb@juniper.net</email>
     </address>
   </author>

   <date year="2017" />

   <area>General</area>

   <workgroup>Internet Engineering Task Force</workgroup>

   <abstract>
     <t>
       The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH)
       Transport layer Protocol specifies that servers and clients
       should support groups with a modulus length of k bits, where the
       recommended minimum value is 1024 bits.  Recent security research
       has shown that a minimum value of 1024 bits is insufficient
       against state-sponsored actors, and possibly any organization with enough computing
       resources.  As such, this document formally
       updates the specification such that the minimum recommended value
       for k is 2048 bits and the group size is 2048 bits at minimum.
       This RFC updates RFC4419 which allowed for DH moduli less than
       2048 bits.
     </t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
       <t>
         <xref target="RFC4419"/> specifies a recommended minimum size
         of 1024 bits for k, which is the modulus length of the DH
         Group.  It also suggests that in all cases, the size of the
         group needs be at least 1024 bits.  This document updates
         <xref target="RFC4419"/> so that the minimum recommended size be
         2048 bits. This recommendation is based on recent research <xref target="LOGJAM"/> on
         DH Group weaknesses. 
       </t>


     <section title="Requirements Language">
       <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
         "OPTIONAL" in this document are to be interpreted as
         described in <xref target="RFC2119">RFC 2119</xref>.
       </t>
     </section>
   </section>

   <section title="2048 bits DH Group">
     <t>
       Recent research <xref target="LOGJAM"/> strongly suggests
       that DH groups that are 1024 bits can be broken by state
       actors, and possibly any organization with enough computing
       resources.  The authors show how they are able to break 768
       bits DH group and extrapolate the attack to 1024 bits DH
       groups.  In their analysis, they show that breaking 1024
      bits can be done with enough computing resources. 
     This document provides the following recommendation: SSH 
     Servers and SSH clients SHOULD support groups with a modulus length
     of k bits where 2048 &lt;&#61; k &lt;&#61; 8192, where it is possible to set k to 3072
      should the need arise in the coming years.
     </t>
     <t>
[RFC4419] specifies 
      a recommended minimum size of 1024 bits for k,
      which is the modulus length of the DH Group.  It also suggests that
      in all cases, the size of the group needs be at least 1024 bits. This
      document updates  <xref target="RFC4419"/> as described below: 
      <list style="symbols">
      <t>
       section 3 Paragraph 9: Servers and
       clients SHOULD support groups with a modulus length of k
       bits where 2048 &lt;&#61; k &lt;&#61; 8192.  The recommended
       minimum values for min and max are 2048 and 8192,
       respectively. k SHOULD be able to be set to 3072 by an implementation should
       the need arise in the coming years.
       </t>
        <t>
        Section 3
       Paragraph 11: In all cases, the size of the group SHOULD be
       at least 2048 bits, with the possibility to be set to 3072 bits should the need
      arise in the coming years.
       </t>
       </list>

     </t>
   </section>
   <section title="Interoperability">
    <t>
   This document keeps the <xref target="RFC4419"/> requirement "The server should
   return the smallest group it knows that is larger than the size the
   client requested. If the server does not know a group that is larger
   than the client request, then it SHOULD return the largest group it
   knows." and updates the sentence that follows to read: "In all cases,
   the size of the returned group SHOULD be at least 2048 bits."
    </t>

</section>


   <section anchor="Security" title="Security Considerations">
     <t>
       This document discusses security issues of DH groups that are
       1024 bits in size, and formally updates the minimum size of DH
       groups to be 2048 bits.  A hostile or "owned" Secure Shell server implementation could
    potentially use Backdoored Diffie-Hellman primes using the methods
    described in <xref target="Backdoor-DH"/> to provide the g,p values
    to be used. Or, they could just send the calculated secret through a
    covert channel of some sort to a passive listener.
     </t>
     <t>
	A malicious client could cause a Denial of Service by making multiple
        connections which are less 2048 bits in size on purpose. Therefore, Operating Systems 
        SHOULD NOT  log DH groups less than 2048 bits in size, 
        as it would create an additional attack surface.
      </t>
   </section>

<section title="IANA Considerations" anchor="sec-iana">

  <t>This document contains no considerations for IANA.</t>

</section>

</middle>

 <back>

   <references title="Normative References">

     &RFC2119;
     &RFC4419;

   </references>

   <references title="Informative References">

     <!-- LOGJAM is an informative rather than a Normative Reference -->

     <reference
         anchor="LOGJAM"
         target="https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf">
       <front>
         <title>
           Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
         </title>
         <author surname="Adrian" initials="D." fullname="David Adrian">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Bhargavan" initials="K."
                 fullname="Karthikeyan Bhargavan">
           <organization>INRIA Paris-Rocquencourt</organization>
         </author>
         <author surname="Durumeric" initials="Z." fullname="Zakir Durumeric">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Gaudry" initials="P." fullname="Pierrick Gaudry">
           <organization>
             INRIA Nancy-Grand Est, CNRS, and Université de Lorraine
           </organization>
         </author>
         <author surname="Green" initials="M." fullname="Matthew Green">
           <organization>Johns Hopkins</organization>
         </author>
         <author surname="Halderman" initials="J. A."
                 fullname="J. Alex Halderman">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Heninger" initials="N." fullname="Nadia Heninger">
           <organization> University of Pennsylvania</organization>
         </author>
         <author surname="Springall" initials="D." fullname="Drew Springall">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Thomé" initials="E." fullname="Emmanuel Thomé">
           <organization>
             INRIA Nancy-Grand Est, CNRS, and Université de Lorraine
           </organization>
         </author>
         <author surname="Valenta" initials="L." fullname="Luke Valenta">
           <organization> University of Pennsylvania</organization>
         </author>
         <author surname="VanderSloot" initials="B."
                 fullname="Benjamin VanderSloot">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Wustrow" initials="E." fullname="Eric Wustrow">
           <organization>Univeristy of Michigan</organization>
         </author>
         <author surname="Zanella-Béguelin" initials="S."
                 fullname="Santiago Zanella-Béguelin">
           <organization>Microsoft Research</organization>
         </author>
         <author surname="Zimmermann" initials="P."
                 fullname="Paul Zimmermann">
           <organization>Univeristy of Michigan</organization>
         </author>
         <date year="2015"/>
       </front>
       <seriesInfo
           name="ACM Conference on Computer and Communications Security (CCS)"
           value="2015" />
     </reference>

  <reference
      anchor="Backdoor-DH"
      target="http://eprint.iacr.org/2016/644.pdf">
    <front>
     <title>How to Backdoor Diffie-Hellman</title>
     <author surname="Wong" initials="D." fullname="David Wong">
     </author> 
     <date month="June" year="2016"/>
    </front>
    <seriesInfo name="Cryptology ePrint Archive" value="Report 2016/644"/>
   </reference>



   </references>


   <!-- Change Log

v00 2017-05-12  LV    Transfer to curdel WG

V01 2017-05-17  MDB   Clean up nits.

V02 2017-06-21 LV Add section on Backdoor-DH, Add section on interoperability, fix character encoding & add LOGJAM in introduction.
V03 2017-06-21 LV Include SSH in title, and rework section 2, into 2 paragraphs.
V04 2017-06-22 LV add xref and fix colon
V05 2017-07-07 LV add list recommended by Daniel, typo from Eric, and make abstract and intro match for attackers.
V06 2017-09-22 LV an->any; typo from warren; fix normative reference from mirja & ipr trust; include section about logging in security considerations,
from benoit claise and OPS DIR; include suggestions about 3072 bits as an option for implementations should the need arise.
   -->
 </back>
</rfc>
