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

"Martin Thomson" <mt@lowentropy.net> Mon, 09 September 2019 08:03 UTC

Return-Path: <mt@lowentropy.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 D601D1200A3 for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 01:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=sDXBRsQG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a2c6l//h
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 Vo6tjo4s2FOx for <tls@ietfa.amsl.com>; Mon, 9 Sep 2019 01:03:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72B8120046 for <tls@ietf.org>; Mon, 9 Sep 2019 01:03:41 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C006F2205E for <tls@ietf.org>; Mon, 9 Sep 2019 04:03:40 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 09 Sep 2019 04:03:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=0Xo25 /2zj1yZBDNvwKJJP2OdGYLL3iMsTWO0jU9C6/4=; b=sDXBRsQGSURUhYLJFxR8D ZppwspjfzCQUL9+dbGABpwfXP+LobWO8NtsJQ93bibwh31t7ZQ8Cy1QrFUC+9vvM 45tXn4pa9alUt5NfzOiifEbDDo0FM904FrG6B9GHJ2coL+XJcuqIuo8y1KyXBbpn PpIY7zN/Xg2FglwYtdzp2Rhj8cIOcJbf7Q1OWxISoiPEkKmo2U5eK3j1AlMF07ZP o5+0I1PwIsTDh6UWdElgfj2E9TJHAWbQTSdxYM0a4ocetefJtQSDPkosvsL14z/1 feE4XAylqfS7pBIWZ+8k3ZzE5pMpc8rsi8bneoWSYtAs19DQrTo3Is9DWsG8IlRr Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=0Xo25/2zj1yZBDNvwKJJP2OdGYLL3iMsTWO0jU9C6 /4=; b=a2c6l//hkUzvXK/TGIQ8Bj/xhwEqfdPUfSczm2tvT10kYJoWDxLB16Ldj GLiIRTD8IBlIuJO4Rldaw+gYYJ3Lj6bNWcGuCbKqGvZKJFpVCxtieFaO6yqD0iQS YAdLtiI18AJISYQPZRd6xiprzGYXTPyUjaNSMBsQlLoMFaV41EcuwizNQrfLgLlk ugLLGKIWGKPwvZxcbyEm5+5tiPEuTg9n7RIKkrNh+YOdItQaDplqAArcLTl0w4qQ v3pii0TUTtsYHhQlq4djJn0d7P/Eb6PXkgHArAgebMcZavvIxmnXCo2rSgJqH/tX rK+J5Vy+CHgTmfgdQQoh1AkbcyUKA==
X-ME-Sender: <xms:XAd2XVdXr67fDs-Y6OFGNPXIi2ud-bCGAa3UnTf-wdDaaxy90_BPYg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudekhedguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmthes lhhofigvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvvggvqdhsvggtuhhrih hthidrohhrghdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:XAd2XdChv1K0n14JQrIv4sJ5gzaaAKrQPxhT7BrhNxMnJ18_jAPFvg> <xmx:XAd2XdWwYfgBgZgHI6zyPULEmPqBpyDRDWmxG5zt7sROGGrmprjm4w> <xmx:XAd2XaXSON8ol2MWS2_xFACgVxR9rsP5AC4vQfcQG8Pu3xsysHtceQ> <xmx:XAd2XdYYQvtTSiQ8DMESLZDU50ZIdxMQpK_oc2JL91dzb_FeWGpOqA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A1A7E00A3; Mon, 9 Sep 2019 04:03:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-188-g385deb1-fmstable-20190905v2
Mime-Version: 1.0
Message-Id: <53dfec39-81cc-4365-a6a4-d5d6399a02b2@www.fastmail.com>
In-Reply-To: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net>
References: <3f3ff654-cec8-c764-c5d6-d8b86dbb3141@gmx.net>
Date: Mon, 09 Sep 2019 18:03:20 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/N_NEH-HG60wM5lGKcSFLTh-_Ars>
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:03:44 -0000

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]
> https://www.ietf.org/proceedings/89/slides/slides-89-irtfopen-1.pdf
> 
> [2]
> http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>