[TLS] New Key derivations for TLS1.3

Michael StJohns <msj@nthpermutation.com> Sat, 21 September 2013 19:43 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA4A721F99E7 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Vlr9UF9NGzPz for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:43:33 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id C9E2611E8137 for <tls@ietf.org>; Sat, 21 Sep 2013 12:43:32 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k4so541314qaq.5 for <tls@ietf.org>; Sat, 21 Sep 2013 12:43:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=lku0O5vFnuZCYStCOlJBmFmBnKJjmg5smXpAYFefL04=; b=lYuvSdqB+TfCjoPOQnYTWo0EOxIdEnN+f3wEKDjoq56TLNjZoqs0Ra/0/VOU0Hhipv 2EbD1fHNURMIeLrsnF3TNGyMp+Y6ifm1Fcs7jVDluiCSGcV1QHzMcHLQLt0qCwIFoWKg wTlnL6N1EUF/6Wh6IhLsFlBR0d9nd/xMnU47/BKwa36Um4DpwTDLWw8YOZ0aBCKmOVw1 1vIvjq9vP627YvVP49/Xp6IOrDZN8d0+HlDhNgafVVSpET9kO6Ju+IyeGeazGyV3QbVT FA/TPlw9vUI79R5AYad8lkRg1ij5jX9nrQKlaaiKW2x4j4BMhQqIfUDTpoGLHMBxoNTl klNg==
X-Gm-Message-State: ALoCoQnfi8Y6kbT73b51XVqUq0242UrhaNZpSjaIXs5aGVBbvOI1QD5lRwYr2PyMNfRjC+jgJqNY
X-Received: by with SMTP id r10mr12385722qeo.28.1379792612256; Sat, 21 Sep 2013 12:43:32 -0700 (PDT)
Received: from [] (c-68-83-212-126.hsd1.md.comcast.net. []) by mx.google.com with ESMTPSA id a2sm28979510qek.7.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:43:31 -0700 (PDT)
Message-ID: <523DF6E3.70408@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:43:31 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="------------030300090309060304090504"
Subject: [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: Sat, 21 Sep 2013 19:43:39 -0000

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 

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.

As a side note, most of the KDFs spec'd by NIST require the key length 
to be included as part of the public information fed into the Key 
Derivation Function (KDF).


>       Computing the Master Secret
>     For all key exchange methods, the same algorithm is used to convert
>     the pre_master_secret into the master_secret.  The pre_master_secret
>     should be deleted from memory once the master_secret has been
>     computed.
>        master_secret = PRF(pre_master_secret, "master secret",
>                            ClientHello.random + ServerHello.random +
48  (expressed as 32 bit NBO)
> )
>                            [0..47];
>     The master secret is always exactly 48 bytes in length.  The length
>     of the premaster secret will vary depending on key exchange method.

Key Calculation
> When keys and MAC keys are generated, the master secret is used as an
>     entropy source.
>     To generate the key material, compute
>        key_block = PRF(SecurityParameters.master_secret,
>                        "key expansion",
>                        SecurityParameters.server_random +
>                        SecurityParameters.client_random +
SecurityParameters.mac_key_length +
SecurityParameters.mac_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.fixed_iv_length +
> );
>     until enough output has been generated.  Then, the key_block is
>     partitioned as follows:
>        client_write_MAC_key[SecurityParameters.mac_key_length]
>        server_write_MAC_key[SecurityParameters.mac_key_length]
>        client_write_key[SecurityParameters.enc_key_length]
>        server_write_key[SecurityParameters.enc_key_length]
>        client_write_IV[SecurityParameters.fixed_iv_length]
>        server_write_IV[SecurityParameters.fixed_iv_length]