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

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 29 November 2013 15:23 UTC

Return-Path: <nmav@redhat.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 C8EE41ADF7E for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 07:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iemYmyhi_r9K for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 07:23:46 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C05D71ADBE5 for <tls@ietf.org>; Fri, 29 Nov 2013 07:23:46 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATFNhOT007750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 10:23:43 -0500
Received: from [10.10.55.102] (vpn-55-102.rdu2.redhat.com [10.10.55.102]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATFNZ5u011067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 10:23:42 -0500
Message-ID: <1385738609.3050.4.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Fri, 29 Nov 2013 16:23:29 +0100
In-Reply-To: <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com> <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com> <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
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 15:23:48 -0000

On Fri, 2013-11-29 at 14:00 +0100, Bodo Moeller wrote:

>         > So, while there has been some support on the list, I don't
>         > believe that this supports the claim that there is rough
>         > consensus for this draft.
>         Where are the opponents on the list? Anyone can hum, but I
>         would like
>         to see them
>         put their names and reasons down

> Decisions at meetings can't silently override mailing list consensus,
> but I think Eric felt that the meeting outcome merely reflected a lack
> of consensus that he'd previously already got from the list -- see his
> previous summary on this list here:
> http://www.ietf.org/mail-archive/web/tls/current/msg10004.html
> 
> (That said, Nikos' complaint seems bogus to me.  Peter's proposal
> seems fine from a security point of view -- as long as clients refuse
> to unnecessarily roll back to SSL 3.0, e.g. using
> draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's
> worth the extra complexity given the other options.)

I think there is some confusion over that. It was a suggestion rather
than a complain; and is not a stopper for such a draft. The fact that
MAC truncation is known to improve security (for HMAC-MD5 and
HMAC-SHA1), does not render non-truncation insecure (as many have
pointed out -including me - there are no known practical attacks against
HMAC-MD5 and HMAC-SHA1).

regards,
Nikos