Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)

["Paterson, Kenny" <[e-mail]>]

On 09/09/2013 14:15, "Alfredo Pironti" <[e-mail]> wrote:

>On Sun, Sep 8, 2013 at 4:59 AM, Peter Saint-Andre <[e-mail]>
>wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> [old thread alert!]
>>
>> On 7/1/13 3:02 AM, Lewis, Nick wrote:
>>>> While people are looking at that, there's also the
>>>> encrypt-then-MAC draft,
>>>> 
>>>>http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-
>>>>03.txt,
>>>>
>>>>
>> which has been stable for about as long, has already been deployed by
>>>> several vendors, and for which TLS extension 0x10 has been de
>>>> facto claimed, so it'd be good to get this published to
>>>> legitimise the use (and to document what's already being deployed
>>>> in production).
>>>
>>> As I recall there were three proposals for resolving the padding
>>> bug in TLS
>>>
>>> 1.       An extension for Pad First (i.e. padding before an
>>> otherwise standard TLS mode of operation)
>>>
>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>>
>>> 3.       The replacement of each existing cipher suite with an
>>> equivalent AEAD one
>>>
>>> Was any consensus achieved as to the best approach?
>>
>> I never saw further discussion on this topic. Are there I-Ds for each
>> approach? #3 seems onerous to me (and doubling the number of cipher
>> suites doesn't seem like a desirable outcome), and as far as I can
>> tell there's no specification for #1.
>
>Approach #1 is defined in
>http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 and we
>have a couple of implementations for it. The main purpose of the I-D
>is to provide means to conceal the payload length within TLS
>fragments; however, a valuable byproduct is to also eliminate the
>recent padding oracle attacks. The I-D applies to all currently
>defined ciphers (block, stream, and AEAD). I'd like to hear your
>comments about it.

Two comments, one on Approach #1, the other on Approach #2:

1. There is some formal support for the "Pad-then-encrypt-then-MAC"
approach being used in the above Approach #1 in the following paper:

Kenneth G. Paterson and Gaven J. Watson

Authenticated-Encryption with Padding: A Formal Security Treatment
Cryptography and Security: From Theory to Applications

Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.

http://link.springer.com/book/10.1007/978-3-642-28368-0



See in particular, Theorem 8 in the paper.

Unfortunately, this paper is behind Springer's paywall. For those on the
list without access, you can access the same content in Chapter 5 (Theorem
5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:

http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf



2. Approach #2 is well supported by theory and is more cryptographically
robust (in the face of bad implementations), provided the involved MAC
algorithm is strong enough.

I briefly reviewed the literature for the state-of-the-art on attacks
against HMAC-H for hash algorithm "H". (See for example
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L.
Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus
more recent work, e.g. Peyrin et al. at Asiacrypt 2012.)

In TLS, we essentially have H = MD5, SHA-1 or SHA-256.  In view of the
literature, of these, I'd recommend deprecating MD5 as the hash if
Approach #2 were to be adopted: current attacks do not seriously threaten
it, but taking a fairly conservative approach seems appropriate here.

Best wishes,

Kenny