[TLS] Key derivation processes

Martin Thomson <martin.thomson@gmail.com> Wed, 30 July 2014 20:58 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 835F31A041F for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 13:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aavAvCUDo7HD for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 13:58:21 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2799C1A040A for <tls@ietf.org>; Wed, 30 Jul 2014 13:58:20 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id w62so1794209wes.22 for <tls@ietf.org>; Wed, 30 Jul 2014 13:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4ho8uY73aBd22qJJUHqNfTvtaLkuLnnuzXw19tVIzHo=; b=lXX4HRRWTrAx88jS7XR849Dvz1fcNL1pFeIQ+0zIYHd/t7j0HMUnzqZdeiBax8S3LE Nzct8YhD0lUNCg0Lxg7aKnqDy/0Pad2+3JU2Pcj+ctl6q1V4wGoY8+4mqcKMlyu4m1Zj ZR1oIL7Godm0PVo76Y2tQmjcdtpNOoMSgMWsdW66WQl1kchLWQKNqGNCbyL4ycI0fddA ouFT+P4ziuPetM6sq5Wn15FKHbpR2rn9qxvjqRnRWGfu0Oi6W/KVoIjhxZxZ35NMPtM7 zwqurjMfUNhTvfD2JsPpwSpzMVT4OXIGAXssuc+KDSGAqvu7Gee+wXL0fg8D7KB5SakY UnXA==
MIME-Version: 1.0
X-Received: by with SMTP id h6mr9338760wiv.65.1406753899578; Wed, 30 Jul 2014 13:58:19 -0700 (PDT)
Received: by with HTTP; Wed, 30 Jul 2014 13:58:19 -0700 (PDT)
Date: Wed, 30 Jul 2014 13:58:19 -0700
Message-ID: <CABkgnnX8_15WLiRGkNzY5aDCSBScQszBxij5fJ-ArG-TCLZ2VA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sfwdlWg08MYMv8EevLdvNrSgxd4
Subject: [TLS] Key derivation processes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Jul 2014 20:58:23 -0000

We've had a bit of discussion thus far about the role of the PRF and
its form.  I think that having a map that describes what material goes
where might help understanding the process.

Here's how I think we should try to structure the flow of keying material:

The handshake determines the PMS.  That's not any different from TLS 1.2.

>From the PMS, we derive a set of other keys and material derived from
those keys.  How that material is subsequently protected can vary
depending on the requirements around its usage.

   - A client read/server write encryption key

   - A client read/server write IV

   - A client write/server read encryption key

   - A client write/server read IV

   - Input for calculating the Finished message

   - A TLS extractor [RFC5705] primitive to be used in place of the MS

   - A TLS unique [RFC5929] value

   - A resumption key that is used as input to the PMS of a resumed connection

Then the PMS is discarded.

This design is basically TLS extractor, which is no coincidence.

The function that is used to derive each of these doesn't matter at
this level of the description. The constraints here are well-known
(triple handshake, etc...). That means that inputs probably include
PMS (which is the resumption key if that's what is going on), plus
everything that appears in the handshake prior to the start of
encryption: version, client random, server random, cipher suite offer
and selection (including group), and DH shares.

I think that this addresses the concerns Mike StJohns has raised with
the current read/write/IV generation function by having independent
streams for keying material and IVs.

I'll note that from the TLS extractor primitive you could derive
several of these items rather than rely on the PMS.  That would allow
their creation to be deferred.  The input to Finished is one
possibility.  TLS unique is another good candidate for this since it
isn't intrinsic to the protocol; though we may want to wait until
after we decide the fate of Finished before we determine the fate of
TLS unique.  That said, you really don't want to derive anything
secret from the TLS extractor key, like the encryption keys, since
that creates a nasty validation problem for extractor.

Rekeying of the form that I proposed simply requires the application
of a one-way function - which might be the same function as above - to
the encryption keys (and IVs) in the affected direction.