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

Achim Kraus <achimkraus@gmx.net> Mon, 09 September 2019 09:48 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 22CDC12004C for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 02:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 Vs_NaD19VsFv for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 02:48:39 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7A64E12002E for <tls@ietf.org>; Mon, 9 Sep 2019 02:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568022515; bh=cnI3GFNr1lGteUCH4ouChzPKvWdmm5HhhQQV1B0egkg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=gsXXkwq0KM4yl8fVVYucQAFaE336EpSgRlgrXdWu6GWqQNPIGcCb76HUddlJ2KL0k Q510KtajyghaUSAo/5B67hqXJ+8oJJDsUggzDuwU0anQt7kdK0tGS1PGpZlBwb+s47 kjJDqUa+j2QkOeTkUPyKIZsxi+ILMVuHDqbYxk9I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.2.208.230]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MSdNs-1hfrUs3nFM-00RW9t; Mon, 09 Sep 2019 11:48:35 +0200
To: Paterson Kenneth <kenny.paterson@inf.ethz.ch>, "tls@ietf.org" <tls@ietf.org>
References: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net> <15B63B34-438D-4776-9797-6A997AC87451@inf.ethz.ch>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <bd38a38f-7a12-bc87-2196-37ca33d136eb@gmx.net>
Date: Mon, 9 Sep 2019 11:48:33 +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: <15B63B34-438D-4776-9797-6A997AC87451@inf.ethz.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:awCVFm2LXQRbEj0Gau2ZhIt+fsyf1yuKrHar1D43PJnFrAQCRda pqFm5ile+Q/+7fPguwSJuDFL1yzyU18WGAsK/7NkF/aKdPofR7JL6MdHHPMadRFfsZwu3aE g/XRM9pUV9Vb5X+RNTJxbG1mkZKNv5GwHqFVbRflqgsYiFlBMEU3C1+lPCiaAYhVizgXtcV hBWCp7Zcz0Qdr31Y06yLA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ewd61FRDi0g=:YK7QEGxMlZOgzHoHdFxtnu QC2FL6HNmIYnrmEu1yfcgq8dTVb0+7rYbXdI85o6tud3BB9g1CmFaoWYCZmRefrIzuUSAH0WT Wjf+HPDasyz2JUJvucgD03iwCwIeHqjs9B0w5+xYYEqnKM17KaGqIDHxz2gzclyRW48LHEAQt mxzoP6fNf4z05YJO4vb1wcqLcHnwQLE5DdsEY/OrLgRP+q9EE6bWu7Y8u9h2rrOB2cxoyzJ63 YWgsk5y+kndzRjw+N75+8/jus6aJDjiOtkEet40TTmruRrXQJJlG4TeUKrc65/XLxEt3/+MqN QVNG5JXXcsiEk+hCLPSZgJ9T6JXwPXr18+bJB+CzCWa3hqBrG8AksR9gi9pT4X9/3/jwO5Tsl eOYaVLmM15OBFIrtQHI+k2c5tMxqbOkw/w6FYY1P5GMeQVbATjt+oD1fyPk2kYJa8CB8Tm2Ox Hqa1Rlkm8usla+EQk+QdOJKeNhVXOiH4pcTsN54D2IQl8CjMMmjVyUGgU/yXfOgphZskNJEO9 tifvxz65L3jBHcrKvBx4G39Whslg6Edsj0jpxuq1PRSE6pbGUvXUP+WyO0oZ+WKCGJxexPYzw AngRL3zjdMPw+5UL3KXqhuT/qgamtVOA/aVCXhRMNmjooVqr9S8jzOnYIdqlF0VF+ShB+Feth Fm7Bgc5W94F0UsSJdtDI/wWiYSEjxRshzEyF3sonS6HT/+fmbDzTmIsepM+VoE5V26NQ6flIz tEnbJ9JM+x6/xxfgph3mcQ0exivSrQs8RVWdc8GKVN3wVYZ5b2PBqUemrHZnqsBe4ijGWNNFX h0haoPmtnfHBEvGEsPOjAFiBnx5NH+SM263Zk5hnYCEixc8JX8IGYilRkEUEZczH/3LJX+7ZA Pf1IRbhhUDbfafi+Ru9IO/FWYmL2i2k7I+NEypeC6n2ChO610qjvz4MpyglvymZL6t8DNYg8C aS8GVjb0YAq0NzCPiay5Pw4MZFeLCrxHeRFjsmEjNxO0wG2sENZEXA1IToOycYUqWkm5dCExz RzvqIv5bRCxtG/LaH7xSh+Bz3BW1wmLs6qWKZI3SD1rIAk6THb3HRzuZgN80E8n+TPKtCg7LX vAnzjpI4VzMc5qx3aQAKNiwokUvkmZTbTlfLGXOyLSAdhCwEcXP1XRo992zDOfB0djwGo6U7m XpEjVGQDKMoq94IAhS5htcRPgchd/P1jWS1I9dG+NxWSjlGufFco4cGKAzn19FgxQE1f4CT4S 7HV5jh9UDR+x81TE8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k5kLRGZCqTpj2c6jTV_EdrTbPU4>
Subject: Re: [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 09:48:41 -0000

Hi Kenny,

 > That would still leave a timing side channel which would reveal
whether the padding length exceeds the amount of data.

Maybe I was not precise:
Regardless of the content of the padding length byte and the result of
it's overflow check, I would always apply b), as you (and others)
recommended in the document. My impression of that "defined padding and
check" was a optimization to skip the MAC calculations. But as lucky13
shows, the MAC must always be calculated and filled up with extra
evaluations!
But, if b) is always applied, the intensive padding check in a) should
be possibly replaced by a simple overflow check without drawback.

 > I'd need to dig into it more to be certain, but my sense is that such
a side channel could be turned into at least a partial plaintext
recovery attack, and possibly a full plaintext recovery attack.

That would be great!

Just one additional question, but if it's too far/deep, just ignore it:
My impression is, that the "plaintext recovery" requires the same
plaintext payload "serveral" times. Then the recover is from the end,
starting with 2 bytes, adding more bytes toward the start of the message
(here it comes, that it must be the same plaintext). With that, I'm
wondering, if such an approach could pass the MAC part (as plaintext
recovery), because this seems to be changing from session to session or
with the record sequence number. Assuming, that therefore the MAC part
must be cut of efficiently, but leave enough for still have an MAC check
on the truncated message, lead to a conclusion, that at least very short
messages are not affected. Does this match your assumptions?

best regards
Achim Kraus

Am 09.09.19 um 10:45 schrieb Paterson  Kenneth:
> Hi Achim,
>
> See below for a comment on your analysis.
>
> -----Original Message-----
> From: TLS <tls-bounces@ietf.org>; on behalf of Achim Kraus <achimkraus@gmx.net>;
> Date: Monday, 9 September 2019 at 09:24
> To: "tls@ietf.org"; <tls@ietf.org>;
> Subject: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2
>
>      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?
>
> That would still leave a timing side channel which would reveal whether the padding length exceeds the amount of data. I'd need to dig into it more to be certain, but my sense is that such a side channel could be turned into at least a partial plaintext recovery attack, and possibly a full plaintext recovery attack.
>
> You might want to read Adam Langley's account of how L13 was addressed in OpenSSL:
>
> https://www.imperialviolet.org/2013/02/04/luckythirteen.html
>
> Regards,
>
> Kenny
>