Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

[Taylor Hornby <[e-mail]>]

On 11/29/2013 01:17 PM, Martin Rex wrote:
> Juho Vähä-Herttua wrote:
>>>
>>> On 29.11.2013, at 18.20, [e-mail] (Martin Rex) wrote:
>>>
>>> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
>>> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
>>> strongly opposed to moving the HMAC into the clear, and into particular
>>> I am strongly opposed to put the HMAC into the clear for the
>>> GenericStreamCipher PDU.
>>
>> You have been quite clear about that, and I've got the impression that
>> you are the only but very vocal opponent of encrypt-then-mac on this list.
>> Although in GenericStreamCipher it offers no benefit, I still haven't
>> seen a convincing argument about why encrypt-then-mac should not be used.
> 
> I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> And the less code needs to be changed to adopt some useful feature,
> the more likely you will see it being adopted for patches/maintenance.
> I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> the GenericStreamCipher processing (which Peter's proposal does).

The quantity of code changes isn't all that matters. The complexity and
the elegance of the changes do too.

Often you can fix something with a one-line hack that makes the code
more confusing, or you can re-write the function and do it properly. I
suspect moving to pad-mac-encrypt instead of pad-encrypt-mac is more
like a one-line hack that would actually make implementation harder.
Most of the encryption APIs I've seen do the padding internally, where
you can't access it to compute the MAC.

Also: Won't you still have to use the padding to *find* the MAC in the
ciphertext, in order to check the MAC before you remove the padding? If
so, then a padding oracle is still possible.

[snip]

> 
>>
>> I'm sure you have good reasons for this opposition, so could you please
>> explain them in one or two sentences. This excluding the "encrypting the
>> HMAC makes it safer" argument, which might be true but as I understand
>> is not well proven.
> 
> The fact that GHASH must be encrypted is sufficient proof that an
> encrypted MAC provides a better safety margin than a plaintext MAC.
> 
> MAC in the clear is only safe when the MAC algorithm is sufficiently
> close to perfect.  We know painfully well that our hash algorithms
> are *not* perfect, so I'm against taking chances, in particular
> for the GenericBlockCipher PDU.
> 

I don't follow this logic. MAC functions are evaluated by letting the
adversary see MAC tags and yet still not being able to forge messages.
Making them public does not reduce their security as a MAC... otherwise
they AREN'T MACs.

[snip]

-- 
Taylor Hornby