IETF Logo Mail Archive

Re: [TLS] TLS1.2 vs TLS1.0

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Tue, 21 May 2013 14:02 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 166D121F8F0E for <tls@ietfa.amsl.com>; Tue, 21 May 2013 07:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjfkRKy1cPNk for <tls@ietfa.amsl.com>; Tue, 21 May 2013 07:02:14 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B36AD21F9768 for <tls@ietf.org>; Tue, 21 May 2013 07:02:12 -0700 (PDT)
Received: from mail140-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 14:02:11 +0000
Received: from mail140-va3 (localhost [127.0.0.1]) by mail140-va3-R.bigfish.com (Postfix) with ESMTP id 70AC5E00B0 for <tls@ietf.org>; Tue, 21 May 2013 14:02:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zz98dIzz1f42h1ee6h1de0h1d18h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h683h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1155h)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT002.eurprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail140-va3 (localhost.localdomain [127.0.0.1]) by mail140-va3 (MessageSwitch) id 1369144925755972_1670; Tue, 21 May 2013 14:02:05 +0000 (UTC)
Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.245]) by mail140-va3.bigfish.com (Postfix) with ESMTP id 81AC7160069 for <tls@ietf.org>; Tue, 21 May 2013 14:02:05 +0000 (UTC)
Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 14:02:02 +0000
Received: from ch1outboundpool.messaging.microsoft.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.107) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 21 May 2013 15:02:00 +0100
Received: from mail11-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 14:01:59 +0000
Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id D560BA0DF9 for <tls@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 21 May 2013 14:01:59 +0000 (UTC)
Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1369144873863106_3813; Tue, 21 May 2013 14:01:13 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id CFFE73C0049; Tue, 21 May 2013 14:01:13 +0000 (UTC)
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 14:01:12 +0000
Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.223]) by AMXPRD0310HT002.eurprd03.prod.outlook.com ([10.255.55.37]) with mapi id 14.16.0311.000; Tue, 21 May 2013 14:01:12 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLS1.2 vs TLS1.0
Thread-Index: AQHOVZuG72FMFJCqDE20fa/zDrAuEJkPqFAAgAADxYA=
Date: Tue, 21 May 2013 14:01:11 +0000
Message-ID: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk>
References: <20130521134742.4B1371A759@ld9781.wdf.sap.corp>
In-Reply-To: <20130521134742.4B1371A759@ld9781.wdf.sap.corp>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.55.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <424B7B79E5320A42891542180CC5F995@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-FOPE-CONNECTOR: Id%36694$Dn%SAP.COM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-FOPE-CONNECTOR: Id%36694$Dn%HERBERG.NAME$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-OriginatorOrg: rhul.ac.uk
Subject: Re: [TLS] TLS1.2 vs TLS1.0
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: Tue, 21 May 2013 14:02:22 -0000

Hi

On 21 May 2013, at 14:47, Martin Rex wrote:

> The alleged (confidentiality) problems that have been demonstrated so far
> are about design-flawed communication peers that require an attacker
> to be able to insert data into the beginning of the TLS-protected
> communication an repeat the request a few thousand times (or more)
> in order to perform plaintext recovery on allegedley confidential
> data that the attacked communication peer willingly inserted into
> the same TLS channel following the data provided by the attacker.

This is an incorrect representation of the known attacks on confidentiality (as I understand them, at least).

- The attacker-injected data does not have to be at the start of the TLS-protected communication.
- The peer-inserted data does not have to follow the attacker-provided data.

> Datagram TLS (DTLS) is another can of worms, because it has an unreasonable
> requirement to ignore unlimited amounts of MAC-failing DTLS records on a
> DTLS connection, but that is a defect from which the stream-oriented
> regular TLS protocols do not suffer.

True. Though the spec for DTLS does allow DTLS implementations to terminate a connection in the event of errors. 

It's just that most (all?) implementations don't.

Cheers!

Kenny

v2.23.0 | Report a Bug | By Email