Re: [TLS] Premaster/Master convention

Michael StJohns <msj@nthpermutation.com> Wed, 30 July 2014 16:21 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357831A028A for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:21:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 gmbIo-DarFbe for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:21:52 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B551A0250 for <tls@ietf.org>; Wed, 30 Jul 2014 09:21:52 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id f51so1811314qge.4 for <tls@ietf.org>; Wed, 30 Jul 2014 09:21:49 -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 :cc:subject:references:in-reply-to:content-type; bh=qnWyvFfz8PPwDaCZ01c3Sh9pMXRx5BRRi9xpbYA85Tk=; b=cdngbq//5HnIakcFUUrWclr84iNeHcU8PZxshlw3M6sfI4mrqj4gF5MYVK4W7gOt5f UWhj4HfLiKRqUqMm506kVY2QKicIDFV0ZIya9zvq9vUAcVfXG5Gvlkc/czFWULy9xaQ7 n0/GX+00VeXO4r/CRBfMkoiXmoiuTnjh43ZcdrwG0J45ISkeikBdKtaKMOOb3neUH1OB vaHYwlqMsQ9qe3nxWyZ+iE/YzrDUq2xmaiLjoEGr0jQdJjBTbs6IQWSvJv5Jf7KtHlZm 3JhMNomPZPS+xNrqMD8xnP6sO6160Rna7LOEwVyYg368k4aFjI63iGf/iY1QxFqHOgpc hrQA==
X-Gm-Message-State: ALoCoQkdvEiNaDE3SCOPlP4K9tbpjpaWWbzUbjdNWf34ewsGABHwqFLGLib3O++JaGIYFhWY/Qsf
X-Received: by 10.224.71.198 with SMTP id i6mr8623378qaj.76.1406737309280; Wed, 30 Jul 2014 09:21:49 -0700 (PDT)
Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id i2sm2975031qge.27.2014.07.30.09.21.48 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 09:21:48 -0700 (PDT)
Message-ID: <53D91B89.3020506@nthpermutation.com>
Date: Wed, 30 Jul 2014 12:21:29 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <53D907B0.3000006@nthpermutation.com> <CABcZeBOCC5-=PVmMyORL7H4BTiixrVWC4TK8=D=sMnqx_Gpcqg@mail.gmail.com>
In-Reply-To: <CABcZeBOCC5-=PVmMyORL7H4BTiixrVWC4TK8=D=sMnqx_Gpcqg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080809040904080001040201"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hb8kJnkT8sKocA36sMERUbjDjE0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Premaster/Master convention
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 16:21:58 -0000

On 7/30/2014 12:00 PM, Eric Rescorla wrote:
> As discussed in the interim we are going to want to roll over the
> MS periodically. Life will be a lot easier if it has a uniform structure.
>
> Moreover, just because we aren't using key transport doesn't mean
> there aren't other mechanisms with funky shared secrets, e.g.,
> PSK.

I don't think either of these are show stoppers - although I don't know 
exactly what you mean by "uniform structure" here.  Do you mean "because 
that's the way its done in TLS1.2 and before and we want backwards 
compatibility"?

In the former case, its pretty simple to do:

(KA)->master_secret -> next_master_secret  - either as part of the first 
context call (to derive the session and handshake keys), or as a 
separate context call (to specifically generate a new master secret.

E.g. the derive looks like:

(KA) -> master_secret
                  -> next_master_secret
                  -> handshake key
                  -> client_write_AEAD
                  -> server_write_AEAD

next_master_secret
          -> next_master_secret
          -> handshake_key
          -> client_write_AEAD
          -> server_write_AEAD

Or it looks like

(KA) -> master_secret (key expand)
          -> handshake key
          -> client_write_AEAD
          -> server_write_AEAD

master_secret (nextmaster)
       -> next_master_secret

(where key expand and nextmaster are differing labels and KDF contexts).

In the PSK case, with key transport, doing the pre_master->master derive 
allows you to mix in random data from both sides so that the 
master_secret isn't only chosen by one side so there's some security 
benefit there.  In the PSK model, that's not an issue as both sides have 
already agreed upon a key.

Mike


>
> -Ekr
>
>
>
> On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns 
> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>
>     Given that TLS1.3 only does KeyAgreement, is there still any
>     reason for the premaster -> master_secret derivation step?  We do
>     (KA)->premaster and then premaster -> master and then
>     master->(session keys).   We could probably do
>     (KA)->master->(session keys) where the master secret is now the KA
>     shared secret rather than premaster.
>
>     1) Is there any security reason for retaining the extra step given
>     there is no longer a KeyTransport mechanism in TLS1.3?
>     2) Are there other *good* - non-security - reasons for retaining
>     the extra step?
>
>     Mike
>
>
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>