[TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

Achim Kraus <achimkraus@gmx.net> Mon, 09 September 2019 07:23 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30880120099 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 00:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 a3ea9u8dRCsg for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 00:23:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 CAF3F120046 for <tls@ietf.org>; Mon, 9 Sep 2019 00:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568013809; bh=aw9g7AspjOjabytu/AE0aJO/9DJW3XWLmr7ZOcTMblI=; h=X-UI-Sender-Class:To:From:Subject:Date; b=kHPM0lgV+CQfinKWcYkQRyrOUwKdigVYZgM6Gv0gyYxLApUTkrRcIYuZJqRTUrkZc N+NKMwTTDWp6PIzXy2V950s6gjceO+DkP152QCxK9EEM/49+I5jdXW9Edalc3c6XuS yUOjFecYHmtg4OPLhysQzZzOI1mFkrL7Ba15W5g4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.2.208.230]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOiHf-1hmVH53uu7-00QEf8 for <tls@ietf.org>; Mon, 09 Sep 2019 09:23:29 +0200
To: tls@ietf.org
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net>
Date: Mon, 9 Sep 2019 09:23:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:SDj3dnRCe8R0mHLrByzJw0fCTwVwF4RKXd0OL+9GyqY49yi/+9F fapaUYjThQZLMObIF2Ji8BJ9APRmHjaiX6dTMTKG1jX1dnti8QCGOWOXGsXVUIq0AlWtTd/ fKHZHe72XNZHP2z0NW5UfoYqHBmf8H93f2hb3zqae9y+WGXCClavHIkGrAFIqjXBwzaY8pf EQJ2P2qelewBc+sXIFMww==
X-UI-Out-Filterresults: notjunk:1;V03:K0:cCIXyBzXWC8=:oqAIMw9yQkRmQl1ZJhps2a +7WlQ0d1J8BtIxm0N1u0zejxMNk4r+gNiPRfp3yEw+NUSl2hSSW4OFAp2CEZuy3FBWsXzi9xw KyvpHhHeGDc2UjcCy8d8gLCAEfdrlcp0SiONvFm36/BpGQ3+Qw2bP8RLmnbByXaP89RGSKtov MPKNQ6CEINpKJcIAP2ZnhvttaXJE/nsxj2cJdPWgqKwnlOtSGGECvDCpzvVUvKSluO8gP8R5e 6b9ie1V8s00zuWVikwJZA/n6jP2I7HygI/mEirVy33MVYCE6nKJcYtPe0gDBJqnnOO8lNOXnY GE6m4Ur6peMIKk2yfk2XCo4Mxe4ZnKPuSU1fHxn8iHXBYL9e0Pbvm1hcbQ9Cj7qJv1uazh+94 pBaq1sgUG4E+cRB9S0NvWSUXW9G0aRVgZzParP0ZlbSioQbyJQsmUOdpakBfa1rNiSsecKkLh K/e17i4GiGL6oC4OWjA/l2gn4CJ0ChMTOu4wpuaBCDk8UAm19Cniga8Z3MN3wV7pCkl6i5tHi YQ/BKLHhJt9/x2IoryQvsk8LpYtKglafaEfFemFr/jh8m0mcYHlP9KXYJPWPvds74sIaPpUDH uGDg4cxR5Z/cCHvsduRverfQYloJRqdIVPS/qJ9olgQRHChCTh0EwHdYae3ZwL13YLwj4/n7X HH0pvDNJZ6E/JaVDOJbiqKW/Ts3c2q7kwnA+uPlqqMhNSx1fK9twsIgrjyJB2zuhO7a/Ep1YF Va+XLbBIi4hrM8xZki8sttIGPrwfJa3RUKEs/CHMLImMIp7GfyiH0DT/Kl0VwvXZCyxqdD38V 3Z5jhKfVxz93arw4pmF1EX3vNg+Kzn47Q2716u7flBZdPYUhdUmvG1jyjxgZ0Qn7xI25guYyz DHWfKjsUItyHvUac/jFkXnxsiE5Wd8EWonlXD3d/ZfKsKaDngM87MtgSO0S1xxth0Yz4drIn1 /GT8o1IY1abvSa2NUPHgmtUsY91h89IDaIDK2xJ0CSNT9IGBv7A0PnHR9QjFZZqlwu07axlpx PvE24B2H6S+brPNEKHPl6s5xpuL6XJiYocy2SZrs8ycoObLn/+lQcpOFpy+fMW6L2EeiTNrTO GVIgpfoqHEr4CZbU9PlcBa+ygGmWeftd49u5thqBEC0c2DeCqZB2sdv0p4y0NXKVdJ4WRJDgY d0JH3AUD3EivNWezMpO+Zefv2nJrHeJLe5IrHad13RzE4V7Vn/g3bIaqmS9ZJ4XyY+J2VAkq1 tAd4SM1cyDNiu/g0D
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lvjMhZl1RWsvyROyaql_zKV1k8A>
Subject: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 09 Sep 2019 07:23:34 -0000

RFC 7457, Lucky 13, mitigation, DTLS 1.2

Dear List,

currently I try to do some investigation about the simplest way to
mitigate the “lucky 13” attack without using RFC 7366.

Therefore I read the slides in [1] and also the recommended mitigation
in [2], which is cited in RFC 7457.

 From the slides, my impression is, that the “defined padding & padding
check” was used to reduce the “timing side channel” of MAC depending on
the data fragment size. Lucky 13 demonstrates, that this “defined
padding” could be tricked out.

The recommended mitigation in [2] describes on page 539 to do,
a) the padding check “time side channel” free by using always “256 compares”
b) and the MAC check “time side channel” free, by adjust the number of
compression function evaluations with extra evaluations on dummy data to
achieve always the same number of evaluations.

FMPOV b) is the one, which closes the “time side channel”.
But a) seems to be more a left over. It doesn’t protect enough, as lucky
13 shows, and complicated algorithms, as “always 256 compares” even on
shorter messages, may harm more.

So, why should that “defined padding” check be done, if b) is applied?

Wouldn’t a simple check, if the padding length exceeds the amount of
data, and on failure, set it to 0, simplify the mitigation?

Additionally, the formula to calculate the extras compression evaluations,

L1=13+plen−t, L2=13+plen−padlen−1−t,

should in my opinion also consider the padlen byte for L1, resulting in

L1=13+plen−1−t

that reduces in some case (1/mac-blocksize) the number of extras
compression evaluations

best regards
Achim Kraus

[1]
https://www.ietf.org/proceedings/89/slides/slides-89-irtfopen-1.pdf

[2]
http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf