[TLS] TLS 1.3 : small fragments attack

Jitendra Lulla <lullajd@yahoo.com> Fri, 29 December 2017 21:51 UTC

Return-Path: <lullajd@yahoo.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 18F571271DF for <tls@ietfa.amsl.com>; Fri, 29 Dec 2017 13:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.98
X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lpVKKEGIgz9m for <tls@ietfa.amsl.com>; Fri, 29 Dec 2017 13:51:21 -0800 (PST)
Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com []) (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 B083B127136 for <tls@ietf.org>; Fri, 29 Dec 2017 13:51:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1514584280; bh=Rv5GCXK5dvCno4rimGPpa5WNDU6fL6CYBPvtX5abmQU=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=Z3KGiHvHp/Awlk0KfzMqfUeMSIQrnyj/HOTMGsmnXbc7CllhO7aUO99p4zzHgHI/fkhIlCdxYmbgVluSPGznwqe6yhnGI8YTEMDD2Kt+zLDHq9kLWw9kgjKXOYzgVC/ZD/bY7mMUpadWWoi5CQQMNmei1v9kdL4GE63KqSU/FJp/1JbjBda7EEWsJJv9etnHn1SZQtndOfMqSCuXszsFgU4PKh+A71Of4Kr6hzO3MyKWdUpzL33CR4oIkNQeUhf8H8MMVzSN+iNsE2iri4AjECZKwmetbXIBNRw8I1PLQmvZfozdN8EMJ/L1FelvHpCi2neK8Y2QFd3XEcXHZeWg8Q==
X-YMail-OSG: nfX2LgAVM1kBwVLH1OcirKSUe96upWTtc7pjf5G691zD5.C5dclqePT5EN1v92w Xg6nFYGDnxMUfcgKinLD1aOEj1XexQkMNxWjykR4GHHLPlMG2m0Y0AKyHs1YY2STd9a.F5KRSZ5J IeJEbAwnC21oKTTJzsPm9JvW2BKZYakSC7rQ1MnPKhQ7fR27HUmC94X0y.cPf_kBzSiEVeCqyE85 H05diu4p126DWAqe6aJpPWPJ1XAbqdZgKB4k3xMy__c8FVptwKAB_eXnnqGztJ8sHZBb7UpDqFAA PqYgAQu28NeBAnBnKnmWpdRbJtwn.axqj95m672sPcXGOVuyMAUz3bvQPRmoiLsJ7IiXksP6NdOd VQuYwxGoFZntGmAlEjC3GrcE2pRNaypxzUkrq8.9xcppRjFgc344lKNCtBf06V9rvtu5Bg4b.p0X 6NlJWnAhNID_R4lTaxINkx_6B3jQ.xofsd1GFTsI_l_GvXaxdEgbuBIXh0JwXlIw5el1Ys34n8HR b57RruA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 29 Dec 2017 21:51:20 +0000
Date: Fri, 29 Dec 2017 21:51:17 +0000 (UTC)
From: Jitendra Lulla <lullajd@yahoo.com>
Reply-To: Jitendra Lulla <lullajd@yahoo.com>
To: <tls@ietf.org>
Message-ID: <1890717233.6710973.1514584277146@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <1890717233.6710973.1514584277146.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.11051 YahooMailBasic Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/J2LSpVLCb9OwuMzUOwMDsl7uKYg>
Subject: [TLS] TLS 1.3 : small fragments attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 29 Dec 2017 21:51:23 -0000


Is it possible for the standards/RFCs to dictate de-prioritization of certain troublesome TLS processing patterns?

The RFCs 
-- may suggest identification of such patterns,
-- may suggest implementation of certain low priority processing queues/threads/executions.

Following is an example troublesome pattern which may or may not be coming from attackers:

Please consider a scenario wherein a server is allowing the clients to upload big files.

The client is mostly doing the transmission in this case.

The client can have a rogue TLS implementation with the following intentional changes:
0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing power requirements) and non paralleliz'able  cipher suite. 
1. After the handshake, always send all the TLS records (Application Data) plain text fragment size which is no greater than 1 Byte.
2. Always send a padding of max possible or big size (eg 256 Bytes)

So the TLS record will look like: (1.2 version)

5 B Hdr + 16 B IV + 1B Cipher Text + 32 B HMAC + 255 B Padding.= 309 Bytes including the tls header.

Additionally the client's network stack can have some changes which may possibly cause the following too:
A. TCP segmentation 
B. IP Fragmentation

Now the server will have to 
i. do ip reassmebly/ TCP reassembly to recover every single TLS record
ii. The TLS record thus recovered will undergo decryption/HMAC verification only to obtain 1 Byte of plaintext application payload.

If many such rogue clients sending huge files to the server, the server will end up denying services to the genuine clients.

Now A and B above are not related to TLS, but the other points do have something to do with the implementations.

If the server's TLS implantation can recognize this pattern [possibly from an attacker], it can give low priority to such requests so that other genuine requests 
may get served without being affected.

If such preventive measures are a part of the RFCs, the implementations will be less vulnerable.