Re: [TLS] New Key derivations for TLS1.3

Wan-Teh Chang <wtc@google.com> Wed, 25 September 2013 01:50 UTC

Return-Path: <wtc@google.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 295A911E80FD for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 18:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1AB3U5Lyamt for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 18:50:02 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35E11E8100 for <tls@ietf.org>; Tue, 24 Sep 2013 18:50:01 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id l4so3718010qcv.10 for <tls@ietf.org>; Tue, 24 Sep 2013 18:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujKTGjiLnMBNTCQBuUEbhG18Gdg7yyW/ts8XyNsVUQ8=; b=VNwkKkRiqCH348y3GDnxcgaJDPZ4vf0u8AcDGobFWINSW0L8lPvLFOfQ0uMCuhIpzm qjrHMzfGcOOZAI4ZkJJAfIvCcbvSyEGCwYARL3xxu5buKcUAz2cCxV3TzAcsvhsoBIFv 5tUbi0b293EJLrV5325GVw0qRE4IDDdfY2f9BobQTGnNGFevJNHtsg2m9GdVUGi27ZOf pg3V7sFtWW1fFXgNRsbm4mC6IIMgZ4gRQ4rM0OpfrCmKy+Q42gxzOyYp6bZeQIgx5gkB X2E/mPMfXA1sv30UBbtS0INkFBnOd4Sa49I9LdUqKdQ3jiU9hQ/FeKavk6Gokdy6Vgie nXqw==
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:date :message-id:subject:from:to:cc:content-type; bh=ujKTGjiLnMBNTCQBuUEbhG18Gdg7yyW/ts8XyNsVUQ8=; b=KEZLlK9qGrW6GJY+VQfKHA6LhzHobptsmJdRhgm9pBL8CFJfGSIR1CAHLgi5mEodcn 8EhIIzh4OqixuFujmsWLyxYTRpPrO+4JRwAHSWuwBcfRuIs0xHRNj7yfi91EMbNmYZ8x He1bfd8TAk7SCQ3n5xXMcQE8E1zDFbRiGghbGgRZ3PnQiYpPDQdQ5vWJzxNuqZAAWASL DUxc+86V2tN0gMu+zpt6A8MEd02uAUgfZ9UU6iElbh/3ad3jOoJ+H77FVa8v235GRAwo iBPX2G4BBYRd+pHwXQlYlPZiIAzYfAghqx4JAIQK4iMs7e1j3Y8UERbeJO3epP89L1Q2 E9fA==
X-Gm-Message-State: ALoCoQnMiLZ12vNJ0kyXX9ZgPd2srohZc7izkkKUC83icDSwiZUKl7FjnnZ0uW5cHaJ2xRKDFQev6Tb/CjqGLgCddyg0w8dSmPxEGBHM/Dd02lylCPMYKr9YvH/sQWUSHzIzAffd/HJB9jl5S1ImrXqqxS14x3eFYqFo7GZczLX4mfX0ihkYkIIh1wl0yUgs3NwQY347NbYQ
MIME-Version: 1.0
X-Received: by 10.224.166.2 with SMTP id k2mr13161529qay.88.1380073798634; Tue, 24 Sep 2013 18:49:58 -0700 (PDT)
Received: by 10.229.176.133 with HTTP; Tue, 24 Sep 2013 18:49:58 -0700 (PDT)
In-Reply-To: <523DF3AF.6060208@nthpermutation.com>
References: <523DF3AF.6060208@nthpermutation.com>
Date: Tue, 24 Sep 2013 18:49:58 -0700
Message-ID: <CALTJjxHBU+1GwKyrPhikWs2OzzQkieFZ4h2vrF+HJdadK=Qp3g@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 25 Sep 2013 01:50:03 -0000

On Sat, Sep 21, 2013 at 12:29 PM, Michael StJohns
<msj@nthpermutation.com> wrote:
> Following up on the previous discussion, I propose the following changes to
> the key derivation steps for TLS.  This adds a length field for each key
> being derived to the PRF seed value.  For the pre-master to master secret
> derivation, this is a single 32 bit length field of value 48.  For the
> master to key expansion derivation, these are 6 32 bit fields each
> representing the length of one of the keys (or IVs to be derived).
>
> By doing this, varying the length of any one of the sub keys completely
> changes the key stream.  That prevents the type of attack described by
> Juraj.

I like this proposal!

> I spec'd 6 fields for the key expansion derivation instead of three to make
> this completely general - and to allow it to be used with the key material
> export RFCs.

Could you elaborate on how your proposed change affects the TLS keying
material exporter RFCs?

Thanks,
Wan-Teh Chang