Re: [TLS] Premaster/Master convention

"Gero, Charlie" <cgero@akamai.com> Wed, 30 July 2014 15:02 UTC

Return-Path: <cgero@akamai.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 483631A0180 for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 08:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 Z_0mdmOfG45Y for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 08:02:25 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 20A6B1A01BA for <tls@ietf.org>; Wed, 30 Jul 2014 08:02:23 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A71EB165787; Wed, 30 Jul 2014 15:02:22 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9C0F0165786; Wed, 30 Jul 2014 15:02:22 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 802E09805B; Wed, 30 Jul 2014 15:02:22 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 30 Jul 2014 11:02:22 -0400
From: "Gero, Charlie" <cgero@akamai.com>
To: 'Michael StJohns' <msj@nthpermutation.com>, "tls@ietf.org" <tls@ietf.org>
Date: Wed, 30 Jul 2014 11:02:20 -0400
Thread-Topic: [TLS] Premaster/Master convention
Thread-Index: Ac+sBphYe7cjK6CITa2Kmo358gpmuQAAEcXQ
Message-ID: <D40A7DE25C5AA54195F82EA553F2446033900BFC0A@USMBX1.msg.corp.akamai.com>
References: <53D907B0.3000006@nthpermutation.com>
In-Reply-To: <53D907B0.3000006@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2phepUW4KWWwJWoxo6nsoq-iKM8
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 15:02:28 -0000

We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms.  It allows us to do splitting between machines that have keys and those that don't (machines in safe locales and those which are simply terminators).  I don't think we could use the same methods we use today without that sub step.  It would make it very difficult for Akamai to adopt 1.3.

-----Original Message-----
From: Michael StJohns [mailto:msj@nthpermutation.com] 
Sent: Wednesday, July 30, 2014 10:57 AM
To: tls@ietf.org
Subject: [TLS] Premaster/Master convention

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
https://www.ietf.org/mailman/listinfo/tls