Re: [TLS] TLS Record Size Limitation

Software Engineer 979 <softeng979@gmail.com> Tue, 08 December 2015 13:21 UTC

Return-Path: <softeng979@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2469C1B2DB2 for <tls@ietfa.amsl.com>; Tue, 8 Dec 2015 05:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvq3sJGZ9ZIt for <tls@ietfa.amsl.com>; Tue, 8 Dec 2015 05:21:35 -0800 (PST)
Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD2F1ACDC9 for <tls@ietf.org>; Tue, 8 Dec 2015 05:21:35 -0800 (PST)
Received: by ioo197 with SMTP id 197so2265110ioo.1 for <tls@ietf.org>; Tue, 08 Dec 2015 05:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fwcucVLnvwCcX0FpCUxX1AMw4c2vXpDwAPVuqBcvyco=; b=QQtoW8XusIu8Bxq7Vb/xDZ3dmD9yqHcRp3fMVZcIdRPb++pzMiYK4h+Y7ARrQxnIi2 cRTsocuhrQYlXsgJei0SV4bMFpuTsHNv7MzI42PvfuKl9xnPuNS8JIhcgROImmWVN+wy DV4OzocXW26Rqjj7M+uI63m20g7/EqFkP4qiEL7bRFFDttTWmUHf58wiO2AE0eEv4rRb /dROn3DwvwA6r5TeWFxtVy5ZeUEHmoqZSdPNZYGAsbPlN5NTriXvr6UTfjX2hl03wqUN a6zM5iV/lqvgOg+6vrU0gEKGTX3ABesY8Vbkm5X9fyeCud5Zcu2AdMJM9u84YJ3KXvT2 yUUA==
MIME-Version: 1.0
X-Received: by 10.107.162.137 with SMTP id l131mr3471019ioe.49.1449580895047; Tue, 08 Dec 2015 05:21:35 -0800 (PST)
Received: by 10.107.146.138 with HTTP; Tue, 8 Dec 2015 05:21:34 -0800 (PST)
In-Reply-To: <op.x9bogpkt3dfyax@killashandra.invalid.invalid>
References: <CANSok=bDBCo4ko9WAoTurt84Krinpsf6_=g3Hq0-JWiiSo3WjQ@mail.gmail.com> <201512080349.59635.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz> <op.x9bogpkt3dfyax@killashandra.invalid.invalid>
Date: Tue, 8 Dec 2015 07:21:34 -0600
Message-ID: <CANSok=bZ3Ri=5xZosVVwJJPq2r0e-kk3ycrCcruzB+V_0_DHkQ@mail.gmail.com>
From: Software Engineer 979 <softeng979@gmail.com>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Content-Type: multipart/alternative; boundary=001a1141bbc652952d052662dada
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3hkIe_9Lcgg_LxX8DZub-6P9COQ>
X-Mailman-Approved-At: Wed, 09 Dec 2015 10:30:38 -0800
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Record Size Limitation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 13:21:37 -0000

Thanks for replies everyone. I also posted the same question the OpenSSL
mailing list. One interesting response stated that the size was limited to
prevent DOS attacks due to resource exhaustion (in the case that data was
being injected).

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

Not sure If I totally buy this as you have the same issue (on a smaller
scale) w/16K buffers. Also, you underlying application implementation would
have alot to due with as well.

On Tue, Dec 8, 2015 at 5:20 AM, Yngve N. Pettersen <yngve@spec-work.net>
wrote:

> On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann <
> pgut001@cs.auckland.ac.nz> wrote:
>
> Dave Garrett <davemgarrett@gmail.com> writes:
>>
>> A TLS extension to negotiate max length might be viable.
>>>
>>
>> I think a better starting point would be to look at the implementation
>> that's
>> causing the problem.  There's nothing magical about a 16K max segment size
>> that causes poor performance, TCP typically has an MSS of 1400-1500
>> bytes, one
>> tenth of the TLS segment size, without there being a 187% loss in
>> throughput
>> so it looks like the problem is in the implementation, not the protocol.
>> I
>> don't see any reason why you couldn't get close to wire speeds, or at
>> least
>> min( crypto speed, wire speed ) for TLS for a properly-done
>> implementation.
>>
>>
> Based on my past experience, a possible reason is that the code does the
> following:
>
> read_event_handler:
>   read data from socket
>   decrypt data
>   handle application data
>   return
>
> rather than:
>
> read event handler:
>   read data from socket
>   queue data for decryption
>   signal decryption handler
>   return
>
> decryption handler:
>   decrypt data
>   handle application data
>
> Another factor I have seen influencing speed is the size of the buffer
> reading from the socket, bigger buffer gives better speed. Within reason,
> of course; IIRC the benefit of increasing the buffer stops at around 5-10%
> of the connection speed. A good rule of thumb is that the buffer should be
> larger than the largest block that you will ever receive over the
> computer's local connection, provided you read the arriving data when you
> are notified about the data.
>
> I recently saw 10x+ speed increase by changing an application's handling
> of these two aspects (on Windows). In that case 300KB buffer was
> sufficient, but I prefer a 1 MB buffer.
>
>
>
> --
> Sincerely,
> Yngve N. Pettersen
>