IETF Logo Mail Archive

Re: [TLS] TLS1.3

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 08 February 2013 10:50 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875E621F8CDE for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 02:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.283
X-Spam-Level:
X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2+iFPmoyvQ for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 02:50:15 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48B21F8AC8 for <tls@ietf.org>; Fri, 8 Feb 2013 02:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320614; x=1391856614; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ynNoU65rlRin0B6+ZPxAikCQsRbS30KE8ZalOWb74TE=; b=rc767J3y52JabKZQgvlRPdJgh1nDZq3caBqwh6nBdz9cO/fy8uNTzq7f /QU5tGg/vDcR+nLGiwJPE9JD7lCrYHxZgEm2k0/nK9eWWIqnsFR/4ccq8 R6ilW+RNSRLgSMlOfjEe+kDMjrdn+iw0qB5wd/kOhvVZQzyTmVTp6S/N/ k=;
X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577828"
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; 08 Feb 2013 23:50:13 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:50:13 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLS1.3
Thread-Index: Ac4F6hJal/eDxHaMSPWvK83bryz+Xw==
Date: Fri, 08 Feb 2013 10:50:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEB0A@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
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] TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Feb 2013 10:50:17 -0000

"Lewis, Nick" <nick.lewis@usa.g4s.com> writes:

>My understanding is that the current attack is due to the MAC revealing the
>length of the plaintext. If the plaintext is pre-padded to a full crypt block
>then a MAC can reveal no more than does the ciphertext itself

>From a very quick read of the paper in an airport lounge (i.e. not a very
detailed one) it looked like the crucial factor was whether you cross a 64-
byte HMAC block or not.  The padding size is dependent on low-level internals
of the MAC algorithm that's used.  In addition while it will stop the current
attack (which, in the case of straight TLS, isn't terribly practical anyway),
it won't stop other attacks.  Using encrypt-then-MAC OTOH stops a whole range
of attacks, including a number of ones that haven't been dreamed up yet,
because the encryption is no longer a possible target.

Peter.

v2.23.0 | Report a Bug | By Email