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

Achim Kraus <> Mon, 09 September 2019 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0BE11200DB for <>; Mon, 9 Sep 2019 01:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DB3OGedgMW6W for <>; Mon, 9 Sep 2019 01:33:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F13221201CE for <>; Mon, 9 Sep 2019 01:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1568018024; bh=sVYg8DE5X3qEGzGiRoJfsWkIaJi0uNkgY79mHVM1wjk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=RLTDiSQFrwzV9qUiq0e7WvJQA7uzb9rVe3PYNT1kU+HocVV4pp4SkE2g8EydIlN6U majmWbHpz+qeB994cn6pSvxV+efwY79G99r0KXICl+StVdaLUOKxCPJKN9Ek1aQxyS E/UZStjnliw1pbY4BFE+MYy6Yui/4VkDllmRhXp0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx001 []) with ESMTPSA (Nemesis) id 0M7Xi3-1iJHlH2Iq7-00xIAo for <>; Mon, 09 Sep 2019 10:33:44 +0200
References: <> <>
From: Achim Kraus <>
Message-ID: <>
Date: Mon, 9 Sep 2019 10:33:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:a91XoDLmMJqLAyemG/1+f6GryupUjSs5Lzz2X4HTOXnv3iZYWhY 0y5rFMjKRhOYJuK0TY2NHnpFHmWPsMBzTEco2lIMY3pkxXiO/apXqT00hSWxOPszYPD6p2Y ba+9WNqEZ6N64LetJV1C/G5o5GmwCdAnEJNYlQ0tb5GKusH26VJ0lpGnR2G0pIKEwf/XJca TcBeFX0jENhckXcZMmJUQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4SXINecpZew=:Mbun01T3r72b3Txlf0D9WS Vzh71M7ye4KaZrxii3KpnEIcP840D0g1BGdtlUBmf56hYVvR7erEioErnuU+PUOlRTAsIB8n7 jzNJVlqcbnDCc8k1FNJMIdF8nkIMIECTApkQlBDonPUzYLaaJPRUFXBwrdyEXPuc16EFvYb2i 2rad/jm9JeXSrrALr/pe2p2nbAR4djzVAXezcq15g95af5w1QukdlSbGz4sXXid9JdwXzLNXo jL+bq063bjt2lQhpTNMssUJrFQ8zoYxdyaIKZOOA0+T1lh3Mr2kLNuBVboUSlKgyEbHtF4sjb S8c4WHe15wQC4CzX4keKxvrSCZNYECVonA7dpNFMZABSFfLe0E8F/p4QcaQl3DnptZCfCmTa/ FBP5q50XpbbjqkkNS2W3/U8fSa4mv65XkwJGiUniE+Yw7qLXxJ+SFJrTu+KwcrZMn0OaT5byM gmJprSyFs0hwuxMfHfGDxShhzZaMPzJnD+fwLWxtwp3khqIqWWa5PCms+n28UdyTRhpvPo00E dGwrEZ8LsQY/3AbRKaE9X+nZzUYzhf6OHKUC2bFM79Kb0rqBCJEMbYo6MFt8dgGirOTxt2IJV QcVRTbNYx4BHnV4+Xjj8dapRoeAM2ZKQ9Gp8WNsdTWs2LFWKvrEp5RaiAwEjv8FF6D2X+80aj 6OaNneDdIhI6z+n8LFnas6IR8ATgTB9G39CDvNj6vh/py167MOslyECxQa9olGCWPc0JwYiqp yxvD5Qfw+zt9R5qIg+GJhTYvZFoAIMMv9n9fPjwopF9xU6ZEoGp1Loalu36EXQdTplAruTz13 h1MJ9VJVJrBrf/LKzNe+HQrZhRHi5nLbZvrcA8lDiVRycYKXpeneN80OyJGR1ClPGZL4ijWMS r4B74jo3OJpMn6nQg9YzpRMJTtzo/6YuXVbidpR5xijboUT6zsvBOgDnOYvcQDFY7Hny7lNC1 S8zwzxyJz7EZ8tHHlOjXZGEsqWQTTelWqKq9AHjp45Fa4tE10exRWAADuUfGCuHoOxrv2CNYR 6SEVYtD5CfjITEY6YBmpB9rZRYEktSUAzGTmp/DqpnjTdNR5fEPyikWKi04ZyCjuPFwNayLdq wzw1w8fHYm2t1ujUNjoQp/dJIPRsDntdVjONmkUpTG/EOFX2AZ8+FkC50pC80NuwmXy3c4yID TMVdZca4sFOFoe5zlYT//yOY5qmn1EnG+GVH3NR/dfX/wOq8uBce7JJ/owTX4J0qTmSA44Hdk x9Mxi2rmlMmYawc/6
Archived-At: <>
Subject: Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Sep 2019 08:33:52 -0000

Hi Martin,

thanks for your answer!

 > Are you able to use an AEAD?
 > I agree that EtM is likely a non-starter, but moving to an AEAD is
just better.

I totally agree! I always recommend to use AEAD and not to start with
CBC, regardless of the flavor. But for "historical reasons", there maybe
users, which are bound to CBC. Though a migration of distribute system
to AEAD (or EtM) may also come with risks, my plan was to offer an
"improvement as temporary solution" to give a little more time for such

 > NSS does the "255 compares" approach, which I think is OK.  In
particular, if the record is shorter, that information is public which
ensures that the timing behaviour is dependent on only public information.

You may do it with the "256 compares".
But my feeling is, this is just a left over and could be replaced by a
simple padding overflow check without drawbacks.

best regards
Achim Kraus

Am 09.09.19 um 10:03 schrieb Martin Thomson:
> Are you able to use an AEAD?
> I agree that EtM is likely a non-starter, but moving to an AEAD is just better.
> NSS does the "255 compares" approach, which I think is OK.  In particular, if the record is shorter, that information is public which ensures that the timing behaviour is dependent on only public information.
> On Mon, Sep 9, 2019, at 17:23, Achim Kraus wrote:
>> 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]
>> [2]
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list