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

Colm MacCárthaigh <colm@allcosts.net> Tue, 21 June 2016 01:42 UTC

Return-Path: <colm@allcosts.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 A433A12DAF5 for <tls@ietfa.amsl.com>; Mon, 20 Jun 2016 18:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 F3cS8M9UuV9P for <tls@ietfa.amsl.com>; Mon, 20 Jun 2016 18:42:32 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDA312D58E for <tls@ietf.org>; Mon, 20 Jun 2016 18:42:31 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id b72so1659704ywa.3 for <tls@ietf.org>; Mon, 20 Jun 2016 18:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AjLyi910NeLAYWEzA8jmb+bxMRWYXxdh7OtatTNE4IU=; b=a3SDJIpGvRafetSYr7JaQgVCErU5osWT77YpSh82amDJtWxQKKzxx6VEWYqn1m1XDT hzqBWvAxcTqfYOZ9XME6sBRKyrtmvjdQ4sShqx+xCmjGaLiPIU6V2sD/Xg+aRZ46+TFN SyZOSGd13HqzwtTf717xK73y8uwZ2jXJUM0xedkw2FFpFRNQXHb0qWIkoubSzaRibxb8 gOdLjwQ52WKoEa3Kj84dqU+ONlNUYlk14GbWiBQ8ULL2+DzoKsA0wwz8D+BF42yxT+rj zHJcTZpEO946qe6vuSB2AWzJu30RPKmphy5hPnShM7L0o1WfW95bTs5YAYdJpDpoesqK txuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AjLyi910NeLAYWEzA8jmb+bxMRWYXxdh7OtatTNE4IU=; b=glse3ktLHgDSr2EPuD8jABbIc+Tt5HMuvU0wUL2opoJyzBZeRMEn9ZAse3WOsqcb/n Z1D/+HZeyz2D1LsrN95jK2xnAkp+1ROwLJtKYhWD0YT5Tvu6XqtsPj3PXBaO2uDJocmi INj9C+WbqpqPZFSfKnr8OC5e/LecZTdiTtKbb6F+9xEw5oGKMCtMVmRg4KcjXUPv4dHe 7z+ZGmL6BS0a9ibLHDP7IRAg0uioBNqlQa4GzABdFYmmGW5aiu8sWTmLtD9HlFouUZYk oGC0/u5gIWcYXcN/pIT3W59gYL0nO8DE3cNRLBLBnH98aL09xhe3aFxzRgqA4ru1zWZE 2hoQ==
X-Gm-Message-State: ALyK8tIV6/SKO0QSROKTy+OcH5Xhnhpff31Kd+PWUmMM79yooWNc0AJZvoLreZ0vOY+JraYeb6+GE5zjsHfUcA==
X-Received: by 10.13.239.2 with SMTP id y2mr12211876ywe.22.1466473351028; Mon, 20 Jun 2016 18:42:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.105.193 with HTTP; Mon, 20 Jun 2016 18:42:29 -0700 (PDT)
In-Reply-To: <CABcZeBOU2a0NER+OQRb4ouhpKkF53ZNyKn5_amAANLrpOBnGWg@mail.gmail.com>
References: <CAOgPGoDRZdJN7DY10tDoEEidVkxeKabCcW_U3vQqaaH6x162gw@mail.gmail.com> <CADi0yUN=FxZHMUtDke4qdaHuvDM2y0aFVCvVJkkpbzXFS0+LsQ@mail.gmail.com> <CABcZeBOU2a0NER+OQRb4ouhpKkF53ZNyKn5_amAANLrpOBnGWg@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Mon, 20 Jun 2016 18:42:29 -0700
Message-ID: <CAAF6GDeHfFdf=m4WNE5Vk0Pya3RkW6HEryXtiMVbV3y_qW3OVA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="94eb2c0350582958bd0535bfef68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Mpq900romv97eHT_nW4QgAO0EuU>
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, 21 Jun 2016 01:42:33 -0000

On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> 2. It's odd to just use a piece of the AEAD cipher (the encryption
> function), especially if we ever had a really non-composite cipher.
> This can be alleviated by using HKDF-Expand to produce the stream
> of bits.
>


If we're going to use a non-standard construction, would it make more sense
to "lose"
the authentication on the inner layer?

E.g.,

1. Encrypt the content type with the "outer" key,
2. Encrypt the with the "inner" key using the same explicit IV.
3. Concatenate the cipher-texts  of 1 and 2.
4. Compute an AAD tag/MAC across all of the data, using the "outer" key.

In that scheme the content type or "outer" key authenticates all of the
data, so you know it's tamper free. Still gross.


-- 
Colm