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

Taylor Hornby <havoc@defuse.ca> Fri, 29 November 2013 20:34 UTC

Return-Path: <havoc@defuse.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147F1ADFA3 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r-BLSVqBBgZ for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:34:12 -0800 (PST)
Received: from defuse.ca (defuse.ca [192.99.8.82]) by ietfa.amsl.com (Postfix) with ESMTP id CBC961ADDAC for <tls@ietf.org>; Fri, 29 Nov 2013 12:34:12 -0800 (PST)
Received: from [192.168.1.102] (S01065404a6902716.cg.shawcable.net [174.0.254.229]) by defuse.ca (Postfix) with ESMTPSA id 294CC1006B1 for <tls@ietf.org>; Fri, 29 Nov 2013 15:34:23 -0500 (EST)
Message-ID: <5298FA4C.7050803@defuse.ca>
Date: Fri, 29 Nov 2013 13:34:20 -0700
From: Taylor Hornby <havoc@defuse.ca>
Organization: https://defuse.ca/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
In-Reply-To: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2013 20:34:14 -0000

On 11/29/2013 01:17 PM, Martin Rex wrote:
> Juho Vähä-Herttua wrote:
>>>
>>> On 29.11.2013, at 18.20, mrex@sap.com (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