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
