<?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-02"
     updates="4419"
     ipr="pre5378Trust200902">

 <front>

   <title abbrev="Recommended minimum modulus size">
     Increase minimum recommended 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 minumum value is 1024 bits.  Recent security research
       has shown that a minimum value of 1024 bits is insufficient
       against state-sponsored actors.  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 suggest s
       that DH groups that are 1024 bits can be broken by state
       actors, and possibly an 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.   [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  [RFC4419] as described below: 
      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.  This document also updates [RFC 4419] Section 3
       Paragraph 11 as follows: In all cases, the size of the group SHOULD be
       at least 2048 bits.
     </t>
   </section>
   <section title="Interoperability">
    <t>
  As state in <xref target="RFC4419"/>, 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.
    </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>
   </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;

   </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>

     &RFC4419;

   </references>


   <!-- Change Log

v00 2017-05-12  LV    Transfer to curdel WG

V01 2017-05-17  MDB   Clean up nits.

V02 2017-06-14 LV Add section on Backdoor-DH, Add section on interoperability, fix character encoding & add LOGJAM in introduction.

   -->
 </back>
</rfc>
