Re: [TLS] Consensus call for keys used in handshake and data messages

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 14 June 2016 19:01 UTC

Return-Path: <ilariliusvaara@welho.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 BC96612DBDD for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 12:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 5VRXccO155uw for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 12:01:47 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31112D901 for <tls@ietf.org>; Tue, 14 Jun 2016 12:01:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8621F5C67; Tue, 14 Jun 2016 22:01:46 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id bwJAjjxpuAVZ; Tue, 14 Jun 2016 22:01:46 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3B9FA21C; Tue, 14 Jun 2016 22:01:46 +0300 (EEST)
Date: Tue, 14 Jun 2016 22:01:44 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <20160614190144.GA9787@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAOgPGoDRZdJN7DY10tDoEEidVkxeKabCcW_U3vQqaaH6x162gw@mail.gmail.com> <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PKWe7hewb0uvv7E7HJWckHgZs_Q>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Consensus call for keys used in handshake and data messages
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, 14 Jun 2016 19:01:51 -0000

On Tue, Jun 14, 2016 at 11:33:11AM +0300, Yoav Nir wrote:
> 
> 
> (1)

+1
 
> One important (for me) use case for handshake messages after the
> original handshake is client certificate authentication. Disclosing
> that the user has just touched the magic resource that causes
> certificate authentication reveals actual information about what
> the user is doing. I haven’t seen an argument about why using the
> same key is similarly harmful.

I too haven't seen an argument (or am I able to construct one
myself) on why using the same key causes more issues than
"more difficult for cryptographers" (without assumptions known
to be false or cause severe problems no matter what).


Such arguments could include e.g. crypto screw (no proof of
exploitability needed), implementability, narrowing works-vs-
correct gap, etc...


About every other issue I could come up with, it seems to be just
as bad with separate keys and public content types (except those
ones that are just worse with public content types of course).



-Ilari