Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

On Wed, Sep 25, 2013 at 12:30 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Eric Rescorla <ekr@rtfm.com> writes:
>
>>Do you think you could address the questions I asked below?
>
> Sorry, given the email avalanche recently and the fact that I wasn't sure what
> the questions were getting at, I'd put them in the TODO list.
>
>> - Because this draft relies on extensions, it seems not to resist
>>   active attack when clients do insecure version fallback
>>   (see for instance:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>
> Right, but given that the problem is broken clients I'm not sure what the
> issue is.  Anything that falls back to older, less secure versions of
> protocols is going to be vulnerable to things that the newer protocols fix.
>
>> - Maybe I am misreading the draft, but I'm unclear on how you get
>>    the TLSCompressed.length for the MAC computation in Section 3.
>>    Does this have the same issue as was raised for McGrew's CBC AEAD
>>    draft?
>
> What was the issue raised for the AEAD draft?  Since I'm not sure what the
> question is asking, the only real response I can give is that there's a number
> of implementations out there that interoperated without problems, so whatever
> the perceived problem is, it doesn't seem to be much of an issue.

The issue is on the receiving side, about computing the
"TLSCompressed.length" field that you need to put in your local
computation of the MAC. I believe
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
as currently defined suffers the same issue.

On receiving side, currently you can't just take the ciphertext and
additional data and locally derive a MAC from it, because the MAC
contains the TLSCompressed.length field, which is the lenght of the
plaintext *before* padding. So, currently, you need to:
1) decrypt
2) split plaintext from pad to recover the TLSCompressed.length value !!!
3) check the MAC

note that step 2 is performing an operation on sensitive data *before*
the MAC has been checked, which actually exposes a very similar
padding oracle to the one that affects current MtPtE.

Fix is however not too difficult: in the MAC, include the whole
"plaintext+padding" length, so that it can be computed directly form
the ciphertext length, without need to decrypt it first.

As a note, this details are already sorted out in
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
where the whole padded length is included in the MAC, and an
"implementation note" paragraph forces the implementer to perform
decryption steps in the right way, avoiding "smart" developers to take
insecure shortcuts.

Best,
Alfredo

>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls