[TLS] New Key derivations for TLS1.3

Michael StJohns <msj@nthpermutation.com> Sat, 21 September 2013 19:29 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 83C3811E8180 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 RGN0WqTs6Y3i for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 12:29:53 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 708B321F9302 for <tls@ietf.org>; Sat, 21 Sep 2013 12:29:53 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id n9so1077880qcw.19 for <tls@ietf.org>; Sat, 21 Sep 2013 12:29:51 -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=MYX6oAPuUfvPOhSBaOKBDDJwFpVGR6DN9imTSc2bkfk=; b=iCS9kfygbbwPSpgmqF0SoBnP/wRAgvzaE2JlbiiQE2s9Ku62uwCzdSQiTsimHLKIq+ 06CtltgpLgliw+8qdhEIT1G24ag70VRS8tKGpAS5nv3kqUvC5puCNQskWjlTDfZlPbTZ 6xbif9oz39T2v4UkndTJd49/xcsiBvBkgjQhjZ1OT6LgsaMBonDPwOtywY3Ge71CO8UN KdsJyI6DhBEhYFDON32/wEgZooqn5pygyHZ1mwF+8GzxZc6GqGixHbo8L3FC8jF2bqkD xFfkKZom9WYb9X6lwkLIo53ZIXMrSydb7QzGa19A4M61t0n2zngx4A2G32lvLEj9ofrn UNqw==
X-Gm-Message-State: ALoCoQnrvUiLPz4yRxgNn88ECQyc/RcuEtd3kM/z527BUy8Y8MQtgCtP9kCDPt/JelvtQop7OSGP
X-Received: by with SMTP id o5mr3134132qeh.80.1379791791725; Sat, 21 Sep 2013 12:29:51 -0700 (PDT)
Received: from [] (c-68-83-212-126.hsd1.md.comcast.net. []) by mx.google.com with ESMTPSA id h20sm28873748qen.5.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:29:51 -0700 (PDT)
Message-ID: <523DF3AF.6060208@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:29:51 -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="------------080100040501050403080001"
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:29:59 -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]