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

Atul Luykx <Atul.Luykx@esat.kuleuven.be> Tue, 19 July 2016 10:12 UTC

Return-Path: <atul.luykx@esat.kuleuven.be>
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 3392912D522 for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 03:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 NKfiXh8MOyY8 for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 03:12:53 -0700 (PDT)
Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAE912D1BC for <tls@ietf.org>; Tue, 19 Jul 2016 03:12:47 -0700 (PDT)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 944D513802F.A8D27
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 944D513802F for <tls@ietf.org>; Tue, 19 Jul 2016 12:12:45 +0200 (CEST)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 8F8ED403B; Tue, 19 Jul 2016 12:12:45 +0200 (CEST)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 8BE6B6002E; Tue, 19 Jul 2016 12:12:45 +0200 (CEST)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 82DCE40; Tue, 19 Jul 2016 12:12:45 +0200 (CEST)
Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 19 Jul 2016 12:12:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 19 Jul 2016 12:12:45 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>
To: David McGrew <mcgrew@cisco.com>
In-Reply-To: <795DBE17-4A95-4AF8-929E-6C247C3324E4@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> <ede4e2ffadd142f781e7a9c04081c825@XCH-RTP-006.cisco.com> <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <D3AB99DD.27C8B%qdang@nist.gov> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> <CACsn0ckFJSEabLOw60-1Pt=e3gLj1W+5yVvWRGzB=avNMQ_X+g@mail.gmail.com> <D3ABBB57.27CAC%qdang@nist.gov> <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> <57dc53aed46f6a29b30d7db2e4ca38f0@esat.kuleuven.be> <795DBE17-4A95-4AF8-929E-6C247C3324E4@cisco.com>
Message-ID: <1759eae16992f43f05b894b0df5c0c98@esat.kuleuven.be>
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99.2 at cobalt
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rv2uHkZaiEeJyAomX5ibv1-8W1s>
Cc: tls@ietf.org
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, 19 Jul 2016 10:12:56 -0000

Hey David,

On 2016-07-19 11:58, David McGrew wrote:
> HI Atul,
> 
>> On Jul 19, 2016, at 2:26 AM, Atul Luykx <Atul.Luykx@esat.kuleuven.be> 
>> wrote:
>> 
>>> What is especially cool about counter mode encryption is how its real
>>> world security degrades more gracefully than CBC mode encryption.  I
>>> am not sure that the FSE paper did a good job of saying it in English
>>> as opposed to math (except for the last sentence of Section 4), but
>>> even though CTR may be just as distinguishable as CBC after some
>>> amount of known plaintext is encrypted, counter mode in practice 
>>> gives
>>> away much less information.
>> 
>> Just to be precise, no attack has been found which illustrates that 
>> CTR mode's security degrades like CBC’s.
> 
> I either don’t understand the sentence, or I disagree with it.  Both
> CTR and CBC are only secure up to the birthday bound, and are
> distinguishable at or beyond that bound.
> 

Sounds good; I was just clarifying the possibility that CTR could be as 
vulnerable as CBC beyond the birthday bound in practice, addressing the 
following sentence:
>> counter mode in practice gives away much less information.
But you're right, I wasn't very clear.


>> Nevertheless, it might be possible to formalize your intuition.
>> 
> 
> Agreed, and what is needed is a measure of the expected amount of
> information an attacker has about the (unknown) target plaintext,
> which would be larger in the CBC case than the CTR case.   This is
> interesting, but of course, we should stick with the standard
> definition of indistinguishability as our security criterion.
> 
> Hope this doesn’t sound like nit picking; I just want to make sure
> that no one thinks I am suggesting that it is OK to use encryption
> systems that are distinguishable.
> 
> best,
> 
> David
> 
>> Atul