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

[Alfredo Pironti <[e-mail]>]

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.

Best,
Alfredo