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

Peter Gutmann <p.gutmann@auckland.ac.nz> Thu, 05 December 2013 03:35 UTC

Return-Path: <p.gutmann@auckland.ac.nz>
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 C335A1AE01D for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 19:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 dH_funVUcVdj for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 19:35:39 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6C1AE01B for <tls@ietf.org>; Wed, 4 Dec 2013 19:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386214536; x=1417750536; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HHzXzLUiezbYFjsMZScNuYa/BCTxIgH5E7SGFVXr728=; b=msxCwOTRWoLj6p8kTgIHbblZoZL8EJoFEU/WfN1KExcSohSjkJf6UyAe nSnZN6w8qtCzx8lS6mKAn6BQwpYBKfi/mznR1CUna6DQzQrzoygm3CR9o Mko09i4pRocZszNeuP+l9oS4zravleCWenzO9bzpf1pQKFavV1R50EoRi U=;
X-IronPort-AV: E=Sophos;i="4.93,830,1378814400"; d="scan'208";a="225812388"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Dec 2013 16:35:35 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.143]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 16:35:34 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: Ac7xaw59XkIZ/XYYTNCsDtR42mtKbQ==
Date: Thu, 05 Dec 2013 03:35:34 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365423E23@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 05 Dec 2013 03:35:43 -0000

Martin Rex <mrex@sap.com> writes:

>TLSv1.2 is a royal PITA for TLS clients, because it requires a reconnect
>fallback facility to be implemented by ***EVERY*** application caller client 
>on top of TLS, ***PLUS*** every application caller will have to memorize the 
>fallback for every destination or the latency will be a royal pain for every 
>new handshake after the TLS session expires from the client-side TLS session 
>cache (when client-side session caching is used at all.  

It's a PITA in general because it introduces a bunch of unexplained and more
or less arbitrary restrictions and silly-walk requirements (e.g. if you do
X with algorithm Y then you also need to do Z) which have no effect except to 
break interoperability.  Things mostly work at the moment because by mutual
unspoken consensus implementers ignore some of the sillier requirements, or
because there's a common mode like using SHA-256 everywhere that seems to 
work OK for all implementations.  At some point in the future though this is 
going to cause headaches when other implementations that don't know how to
interpret the spec in order to make things work come along.

Peter.