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

"Paterson Kenneth" <kenny.paterson@inf.ethz.ch> Mon, 09 September 2019 08:45 UTC

Return-Path: <kenny.paterson@inf.ethz.ch>
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 6632E120105 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 01:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HgxAiLcc18bG for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 01:45:35 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9465C1200E9 for <tls@ietf.org>; Mon, 9 Sep 2019 01:45:33 -0700 (PDT)
Received: from mailm214.d.ethz.ch (129.132.139.38) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 9 Sep 2019 10:45:33 +0200
Received: from mailm114.d.ethz.ch (2001:67c:10ec:5602::26) by mailm214.d.ethz.ch (2001:67c:10ec:5603::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Mon, 9 Sep 2019 10:45:29 +0200
Received: from mailm114.d.ethz.ch ([fe80::7114:d795:2066:d254]) by mailm114.d.ethz.ch ([fe80::7114:d795:2066:d254%3]) with mapi id 15.01.1779.004; Mon, 9 Sep 2019 10:45:29 +0200
From: "Paterson Kenneth" <kenny.paterson@inf.ethz.ch>
To: Achim Kraus <achimkraus@gmx.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2
Thread-Index: AQHVZt+gq7brsQuAZUmWx5AkWPY+nacjCB6A
Date: Mon, 9 Sep 2019 08:45:29 +0000
Message-ID: <15B63B34-438D-4776-9797-6A997AC87451@inf.ethz.ch>
References: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net>
In-Reply-To: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net>
Accept-Language: de-CH, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.6.35.245]
x-tm-snts-smtp: 0DB218CADFF87BA6F465C8B20B62ED4EA2D53E05ECF4BEBD4D81E1A2CEF924BC2000:8
Content-Type: text/plain; charset="utf-8"
Content-ID: <A8A5E0F8AF14FB47A817B36CC06D4020@intern.ethz.ch>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/C_i_Hgl6dCo8G5Pup4LknMZ74XM>
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 08:45:39 -0000

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