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

Alfredo Pironti <alfredo@pironti.eu> Sat, 30 November 2013 17:25 UTC

Return-Path: <alfredo@pironti.eu>
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 9FE761AE472 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 LcCO-iHGWuqS for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:25:15 -0800 (PST)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2241AE471 for <tls@ietf.org>; Sat, 30 Nov 2013 09:25:14 -0800 (PST)
Received: by mail-oa0-f47.google.com with SMTP id k1so11452014oag.20 for <tls@ietf.org>; Sat, 30 Nov 2013 09:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=NaEnJEPLAoGTPi48cXgRLvrWLBzaOOz0s3d3AvorCjAgoCKuwHhGZF317KIuPdrgTy RMjl/plh786lnDV9X9QIy8wqeQRldWO2lnZk/iiOQLCbDGYisdwvTadqFf3bR30CEEvw ZpSGwrEHeapKHwBXtNmorLUjFNJMby7znpZK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=TdOshGYXUCmCd3bBb7c7r8JxVvD4pndky1xNmlFzT98jiB7ZNSlv4VKXB+72XA9CaG OMtYTGoFRHE8AVIMz7yXVjIiLhdVien+Wbwr7OjMU2B7ZvxvKzXopRcd6mDClElWx8Lg wxlBpJyH57qavzeIdFYmTGDoFh9kRGjUcC/S6k0jy1gSR/+EtcKDvrihvBIzPb/Pv7Af g7lz977pKvtnerPiMsfkB1ikJIxI7gOgLS6GTuem4EsaxAcsZD+nugq8fQ6DtCrVJJLs YYoCKBnUHTk6CN/arFYmRkeA1XKrmUrphElJLBkCEv5NBl+358/M/zJw2kSHCuVcBkF+ U/cg==
X-Gm-Message-State: ALoCoQl3m7tri/gsQkdXZKxAsz5C6b4ifT+7/Um339DjTr/rxb3sMz+o/4djs3KR285CXx2M28PB
MIME-Version: 1.0
X-Received: by 10.60.56.3 with SMTP id w3mr29364298oep.37.1385832312900; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
Received: by 10.76.114.194 with HTTP; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
Date: Sat, 30 Nov 2013 18:25:12 +0100
Message-ID: <CALR0ui+Ao6cd0h94W=0Yovs57hNCYL-bqqNwWa00T3kWDW1SgA@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
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: Sat, 30 Nov 2013 17:25:16 -0000

>
> I'm going to prepare a proposal I-D to do exactly (and only) what
> Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
> change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
> When doing this, we can also consistently adopt the explicit random IV
> (which can be implemented as a random confounder) to all versions of TLS.

Please don't!
I think [1] does just what you're asking for. With 2 differences we
can agree upon:
1) Adding explicit IVs everywhere is a nice idea, and I'm up to add it
to the I-D.
2) If the paragraphs on non-GenericBlockCiphers really annoy you, just
ignore them.
To get a compliant implementation with non-block ciphers, all you have to do
is to add a 2-bytes empty vector to user data when sending, and parsing it when
receiving. All TLS implementations have a function for this, and it's
then a 2-lines patch.

>
> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

I disagree with this. The more we add SSL3-compatible hacks, the more excuses
we give to vendors and to this WG to keep using SSL3.

[1] http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01

Alfredo

>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls