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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 15 June 2016 13:44 UTC

Return-Path: <dkg@fifthhorseman.net>
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 1DF2212D69B for <tls@ietfa.amsl.com>; Wed, 15 Jun 2016 06:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 heSfNBfgQQEh for <tls@ietfa.amsl.com>; Wed, 15 Jun 2016 06:44:23 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3F12D60E for <tls@ietf.org>; Wed, 15 Jun 2016 06:44:23 -0700 (PDT)
Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 80EA2F98B; Wed, 15 Jun 2016 09:44:22 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 3357521EB9; Wed, 15 Jun 2016 09:44:22 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Yoav Nir <ynir.ietf@gmail.com>, Nikos Mavrogiannopoulos <nmav@redhat.com>
In-Reply-To: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com>
References: <CAOgPGoDRZdJN7DY10tDoEEidVkxeKabCcW_U3vQqaaH6x162gw@mail.gmail.com> <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com>
User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 15 Jun 2016 09:44:18 -0400
Message-ID: <871t3y1s99.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ikdsn_Lu_tpRv5ve9ExK2xgd834>
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: Wed, 15 Jun 2016 13:44:25 -0000

On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
> I disagree that this is a low level crypto decision, or at least that this is mainly so. 
>
> There is the question of whether using the same key for application data and handshake is harmful. That question is mainly low level crypto and could be asked of CFRG.
>
> There is the other question of whether exposing the fact that there are handshake messages and when they occur is harmful. That is security-related, but not at all related to crypto.
>
> Weighing these two potential harms against each other and coming to a decision is entirely an engineering issue, and we should not offload that to CFRG.

To be clear, we're being asked to trade these things off against each
other here, but there are other options which were ruled out in the
prior framing of the question which don't rule either of them out.

In particular, if we're willing to pay the cost of a slightly more
complex key schedule (and an increased TLS record size), we could have
"packet header" keys which protect the content-type itself for all
non-cleartext TLS records.  If we do that, these keys might as well also
be used to protect the TLS record size itself.  This would result in an
opaque data stream (though obviously record size would still leak in
DTLS, and timing and framing is still likely to leak the record size in
the lowest-latency TLS applications).

The current framing of the question pits these things against each other
as a tradeoff, but if we want to, we could protect them all.

   --dkg