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

From: Achim Kraus <[email-masked]>
Date: Mon, 9 Sep 2019 09:23:26 +0200

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 09 Sep 2019 18:03:20 +1000

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:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Achim Kraus <[email-masked]>
Date: Mon, 9 Sep 2019 10:33:43 +0200

Hi Martin,

thanks for your answer!

 > 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
migrations.

 > 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

---

From: "Paterson Kenneth" <[email-masked]>
Date: Mon, 9 Sep 2019 08:45:29 +0000

Hi Achim,

See below for a comment on your analysis.

-----Original Message-----
From: TLS <[email-masked]> on behalf of Achim Kraus <[email-masked]>
Date: Monday, 9 September 2019 at 09:24
To: "[email-masked]" <[email-masked]>
Subject: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

    Dear List,

    

    

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

---

From: Achim Kraus <[email-masked]>
Date: Mon, 9 Sep 2019 11:48:33 +0200

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

---

From: "Paterson Kenneth" <[email-masked]>
Date: Mon, 9 Sep 2019 12:59:23 +0000

Hi Achim,

Let's take this off the list, as the details are probably not too interesting to many folks these days?

Cheers

Kenny

-----Original Message-----
From: Achim Kraus <[email-masked]>
Date: Monday, 9 September 2019 at 11:49
To: Paterson  Kenneth <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

    Hi Kenny,

    Maybe I was not precise:

    That would be great!

    best regards
    Achim Kraus

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 Sep 2019 19:28:35 +0000

Martin Thomson <[email-masked]> writes:

>I agree that EtM is likely a non-starter

Just out of curiosity, why do you say EtM is a non-starter?  It neatly fixes
the problems caused my MtE.

Peter.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Sep 2019 14:48:08 +1000

> the problems caused my MtE.

I don't know that many stacks implement it.  We don't.  There's nothing wrong with it, but it's down to practicalities.  My understand is that implementing MtE isn't justified relative to just moving to an AEAD.