Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 12 July 2016 18:06 UTC

Return-Path: <sfluhrer@cisco.com>
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 7FA6712D59F for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 11:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 H2WGaBNpdXiG for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 11:06:28 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4647512D0D8 for <tls@ietf.org>; Tue, 12 Jul 2016 11:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3204; q=dns/txt; s=iport; t=1468346788; x=1469556388; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Zon9okD8SJ0gtViXjYbIYc0ikUAa099joVDDMratsg4=; b=fv5hDJf7bA/YjU4NsragXkm+zPQapQyEG4/vBpsiWeRnGMfXn3SrUqN9 OWczT9NilnhWB7s6nKQLzBGttC/mTCPTYOVF2/3Wjkjoc47JfuVItdyKJ gqIGRmgyfs8aFVkQFtCoOrrqJJ8iUjOPP9P7wprSvUj/oBZlqU1PBCfuw U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AhAgBbMYVX/4kNJK1cDoMwgVIGuQOBeYYYAhyBGTgUAQEBAQEBAWUnhFwBAQQBIxFRBAIBCBEEAQEBAgIjAwICAjAUAQgIAgQBEgiIIAixD48NAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmETYQdASoQI4JHgloFmRsBjkyPNYQ7i1gBHjaCBgMcgRE7bodhASUffwEBAQ
X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="295081913"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 18:06:27 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6CI6RrS025055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 18:06:27 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 14:06:26 -0400
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 14:06:26 -0400
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, "Dang, Quynh (Fed)" <quynh.dang@nist.gov>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26epuiTmg3+eU0yJfAjoGH7+FKAVB4KAgAAQs4CAABMcgP//w17wgABTKwCAAAjnAIAAA3GA///H5gA=
Date: Tue, 12 Jul 2016 18:06:26 +0000
Message-ID: <ede4e2ffadd142f781e7a9c04081c825@XCH-RTP-006.cisco.com>
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <D3AA5BD6.27AC0%qdang@nist.gov> <D3AAB674.709EA%kenny.paterson@rhul.ac.uk> <D3AA7549.27B09%qdang@nist.gov> <d1f35d74e93b4067bf17f587b904ebff@XCH-RTP-006.cisco.com> <D3AAD721.70A11%kenny.paterson@rhul.ac.uk> <D3AA9B01.27B9F%qdang@nist.gov> <D3AAE2B7.70A78%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D3AAE2B7.70A78%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.52]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/egLiYP3ylNCB_TxgP_YkMolaGbE>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Jul 2016 18:06:29 -0000

> -----Original Message-----
> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk]
> Sent: Tuesday, July 12, 2016 1:17 PM
> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
> 
> Hi
> 
> On 12/07/2016 18:04, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote:
> 
> >Hi Kenny,
> >
> >On 7/12/16, 12:33 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
> wrote:
> >
> >>Finally, you write "to come to the 2^38 record limit, they assume that
> >>each record is the maximum 2^14 bytes". For clarity, we did not
> >>recommend a limit of 2^38 records. That's Quynh's preferred number,
> >>and is unsupported by our analysis.
> >
> >What is problem with my suggestion even with the record size being the
> >maximum value?
> 
> There may be no problem with your suggestion. I was simply trying to make it
> clear that 2^38 records was your suggestion for the record limit and not ours.
> Indeed, if one reads our note carefully, one will find that we do not make any
> specific recommendations. We consider the decision to be one for the WG;
> our preferred role is to supply the analysis and help interpret it if people
> want that. Part of that involves correcting possible misconceptions and
> misinterpretations before they get out of hand.
> 
> Now 2^38 does come out of our analysis if you are willing to accept single key
> attack security (in the indistinguishability sense) of 2^{-32}. So in that limited
> sense, 2^38 is supported by our analysis. But it is not our recommendation.
> 
> But, speaking now in a personal capacity, I consider that security margin to be
> too small (i.e. I think that 2^{-32} is too big a success probability).

To be clear, this probability is that an attacker would be able to take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential (but incorrect) plaintext, and with probability 2^{-32}, be able to determine that this plaintext was not the one used for the ciphertext (and with probability 0.999999999767..., know nothing about whether his guessed plaintext was correct or not).

I'm just trying to get people to understand what we're talking about.  This is not "with probability 2^{-32}, he can recover the plaintext"


> 
> Regards,
> 
> Kenny