Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

On Tue, Jan 13, 2015 at 9:52 AM, Paterson, Kenny
<Kenny.Paterson@rhul.ac.uk> wrote:
> Hi
>
> On 13/01/2015 16:39, "Manuel Pégourié-Gonnard" <mpg@polarssl.org> wrote:
>>On 06/01/2015 11:35, Paterson, Kenny wrote:
>>> It's good that nothing supports the truncated-MAC extension, because, in
>>> combination with TLS's support for variable length padding, it
>>>introduces
>>> a security vulnerability. See:
>>>
>>> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
>>>
>>>
>>> which shows that if the tag size (MAC length) is shorter than the
>>>CBC-mode
>>> block size, then there's a distinguishing attack that can tell the
>>> difference between the encryption of a short message and a longer
>>>message
>>> (even though both are padded to the same size before encryption).
>>>
>>But if one does not expect any length hiding, is there still a problem
>>with
>>truncated MACs?
>
> I think one would expect length hiding at least up to the granularity of
> the block size in TLS with CBC mode. (The RFC even suggests that more
> should be possible: "Lengths longer than necessary might be desirable to
> frustrate attacks on a protocol that are based on analysis of the lengths
> of exchanged messages." [1])
>
> As a special case of the general attack, consider a notional application
> using TLS that sends either the message "YES" or the message "NO". Suppose
> we negotiate truncated MACs, and the TLS Record Protocol implementation
> selects the amount of padding to add at random (from the set of possible
> padding lengths allowed under the TLS padding scheme).
>
> By truncating the ciphertext, doing some bit flipping, and reinjecting the
> modified ciphertext, an adversary can tell whether "YES" or "NO" was
> originally encrypted. (This assumes that the minimum amount of padding is
> NOT selected; this happens with probability roughly 15/16 under the above
> assumptions.)
>
> I'd consider that to be an attack in your "don't expect any length hiding"
> setting - after all, the difference in plaintext lengths is just 1 byte,
> which is well below the CBC-mode block size. Does that seem reasonable, or
> is it still outside your attack model?

>From what I understand, when AES-GCM is used there isn't any padding,
and the length of the encrypted record is equal to the unencrypted one
plus the tag, so this attack still works. So if we accept this attack
(and I think we should), then the way AEAD ciphers are used in TLS are
also insecure. I believe this attack got used to determine autofill
entries in the Google search bar via passive observation, but I've not
dug up the paper, so my memory may be wrong.

To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.

Sincerely,
Watson Ladd

>
> Cheers
>
> Kenny
>
> [1] RFC 5246, Section 6.2.3.2
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls