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

Watson Ladd <watsonbladd@gmail.com> Fri, 29 November 2013 18:23 UTC

Return-Path: <watsonbladd@gmail.com>
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 D0A381AD948 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 zwkALMHdGFAc for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:23:45 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC911AD8F6 for <tls@ietf.org>; Fri, 29 Nov 2013 10:23:45 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so9384016wes.26 for <tls@ietf.org>; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5cJhoYs7JYWeAFZ7v92WnIE5nuKIxu/1emxd7c9TH/s=; b=dveQBYSzryr3yvD3xTH8iIrXW/77yXgPVPyPh1KP0+LlYhhQloS5edKiOVwEAqXijh w+ZwZvDKBP5hUEKKYs/bFf5v634qj3tjIBMFj+3KD9RMUWjLNE8poJfpDaVKugYZqtvp 8bhaQlIU//LkbPN3MuOrh7e0pDipDacYzv385FWB6nrDQBQ5A+HSEaKXVF5sqEieAApo K8/NDlQd0XO3dZYXKJWQAbsUe2fNpGWIf/qMtZ87zusKVCJZYuchR7TyhpU9Q/O7z0AO 7/Mc+FKq5gb7IOl80kF6VogiQb9RZiD2eu4ZeF1eHpaBL8z8Tz9WWL14cAE6w9enLaR+ Po5w==
MIME-Version: 1.0
X-Received: by 10.180.36.105 with SMTP id p9mr7875375wij.58.1385749423804; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
In-Reply-To: <1385748814.5805.4.camel@aspire.lan>
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi> <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com> <1385748814.5805.4.camel@aspire.lan>
Date: Fri, 29 Nov 2013 10:23:43 -0800
Message-ID: <CACsn0c=3OJ30Yq0dZHe_P3sM9A5g3smyzGAFT=XL_gDh5C8Ayg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
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 18:23:48 -0000

On Fri, Nov 29, 2013 at 10:13 AM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> On Fri, 2013-11-29 at 09:26 -0800, Robert Ransom wrote:
>
>> > 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.
>>
>> Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
>> don't know of any others.
>
> It seems I'll have to repeat that. I don't oppose this draft. I prefer
> an alternative [1], which was not mentioned in the IETF88 meeting. So if
> the question would be AEAD (i.e, not a fix) or encrypt-then-mac, I'd go
> with the latter. If the question is [1] or encrypt-then-mac I'd go with
> the former.
Why do you prefer this alternative?
AEAD is a fix, provided we deploy it. But that isn't happening for
whatever reason.
I suspect that we will soon learn that all fixes do not get deployed
for mysterious reasons.
Solution: get it right the first time.
>
>> > 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.
>> "not well proven" is the wrong phrase here.  Marsh Ray solidly
>> debunked it.
>
> I don't quite understand that. No-one questioned his observations in any
> point at any previous discussion. Please review them to understand where
> I stand.
So if HMAC is only a universal hash then HMAC followed by counter mode
is secure, but
HMAC followed by CBC is secure up to a collision of the chaining
value. This analysis assumes
the HMAC falls in a block.

But remember HMAC is essentially H(k||H(k||m)). In particular if the
H(k||m) is a universal hash function,
and H(k||..) satisfies some sort of keyed security assumption (PRF for
fixed length?) HMAC is secure.

So the only way HMAC followed by encrypt is more secure than encrypt
followed by HMAC is if things
break in a really weird way.
Sincerely,
Watson Ladd
>
> regards,
> Nikos
>
> [1].
> http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin