<div dir="ltr"><div>Ben,</div><div><br></div>I'm pretty new to TLS, so please bear with me. I was thinking through what you said and I had a few questions. Couldn't you pull off the same DOS attack using the existing 16K message size today. The scale of the DOS attack would have to be larger as the packet size is smaller, but the vector of attack still exists today correct?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 2:46 PM, Benjamin Kaduk <span dir="ltr"><<a href="mailto:bkaduk@akamai.com" target="_blank">bkaduk@akamai.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    On 12/07/2015 02:43 PM, Software Engineer 979 wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">Hello,
        <div><br>
        </div>
        <div>I'm currently developing an data transfer application using
          OpenSSL. The application is required to securely transfer
          large amounts of data over a low latency/high bandwidth
          network. The data being transferred lives in a 3rd part
          application that uses 1 MB buffer to transfer data to my
          application. When I hook OpenSSL into my application I notice
          an appreciable decline in network throughput. I've traced the
          issue the default TLS record size of 16K. The smaller record
          size causes the 3rd party application's buffer to be segmented
          into 4 16K buffers per write and the resulting overhead
          considerably slows things down. I've since modified the
          version of OpenSSL that I'm using to support an arbitrary TLS
          record size allowing OpenSSL to scale up to 1MB or larger TLS
          record size. Since this change, my network throughput has
          dramatically increased (187% degradation down to 33%). </div>
        <div><br>
        </div>
        <div>I subsequently checked the TLS RFC to determine why a 16K
          record size was being used, and all could find was the
          following:</div>
        <div><br>
        </div>
        <pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">length
      The length (in bytes) of the following TLSCompressed.fragment. </pre>
        <div><span style="color:rgb(0,0,0);font-size:13.3333px">     
            The length MUST NOT exceed 2^14 + 1024.</span></div>
        <div><br>
        </div>
        <div>The language here is pretty explicit stating that the
          length must not exceed 16K (+ some change).Does anyone know
          the reason for this? Is there a cryptographic reason why we
          shouldn't exceed this message size? Based on my limited
          experiment, it would appear that a larger record size would
          benefit low latency/high bandwidth networks.</div>
        <br>
      </div>
    </blockquote>
    <br></span>
    The peer is required to buffer the entire record before processing
    it, at at that point the data could be from an untrusted
    party/attacker.  So the limit is for protection against
    denial-of-service via resource exhaustion.<br>
    <br>
    -Ben<br>
  </div>

<br>_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div>