Re: [TLS] Premaster/Master convention

Michael StJohns <msj@nthpermutation.com> Thu, 31 July 2014 17:28 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 11AAC1A0310 for <tls@ietfa.amsl.com>; Thu, 31 Jul 2014 10:28:24 -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 P7KowhYZpMWt for <tls@ietfa.amsl.com>; Thu, 31 Jul 2014 10:28:21 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12371A0099 for <tls@ietf.org>; Thu, 31 Jul 2014 10:28:21 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rp18so4181478iec.33 for <tls@ietf.org>; Thu, 31 Jul 2014 10:28:21 -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=ezub7ns19AwxdmVDbMxiYQP+sjfGNtm+TzqOBi7eZtI=; b=CRxVqJzoaSlHDC4KmDf/hmjLZBO9+FHZRlhrcnIYTOL14dlqCqpOFGSVtOWudTNR7Z JuGyJ3azvnWAwLddcUV4AQzeDuY8eMmD7KOg13mCntN/5eAsyTEsvujRhUa3fU37J6W4 JkVnX9JybkFaYoCfM/mHbits/WSFfgu9R+xMPRA5RUm9pJuf58CcziliWGPo4GhO3vSw G0PEmBFb7tKZB4xQIU70bA5jU2uK/sF8+8d0bIt3F0OjyjSr0xBfv5V8PLniBywimkx9 l+smhLUnjj4iRB0AqOEWPsZPLep1OgbiIrkH6Zofq0kT43hzHlOT8Kyv+dZ7EFhuqk/x SjSw==
X-Gm-Message-State: ALoCoQkl1MtHobKlu3rPHScgwAgaSOKY0H6TcDF93wOtoemBu17tL80LJvHrTrTpXWiQiIwCmtPM
X-Received: by 10.50.33.100 with SMTP id q4mr75248igi.8.1406827700907; Thu, 31 Jul 2014 10:28:20 -0700 (PDT)
Received: from [10.90.197.183] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id e1sm13217345igx.21.2014.07.31.10.28.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 10:28:20 -0700 (PDT)
Message-ID: <53DA7CB6.6030400@nthpermutation.com>
Date: Thu, 31 Jul 2014 13:28:22 -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: "Gero, Charlie" <cgero@akamai.com>
References: <53D907B0.3000006@nthpermutation.com> <D40A7DE25C5AA54195F82EA553F2446033900BFC0A@USMBX1.msg.corp.akamai.com> <53D91332.9070103@nthpermutation.com> <D40A7DE25C5AA54195F82EA553F2446033900BFC15@USMBX1.msg.corp.akamai.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com>
In-Reply-To: <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com>
Content-Type: multipart/alternative; boundary="------------000101050903040202010502"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fr1D3fBPmGyAm3lBg5m85j5ocAQ
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: Thu, 31 Jul 2014 17:28:24 -0000

On 7/30/2014 8:44 PM, Gero, Charlie wrote:
> Michael,
>
> Respectfully, there are things that we can and can not divulge.  I 
> will continue to monitor this path and will update as necessary if 
> removal of the PMS to MS step looks like it is gaining traction.  I'm 
> not sure it is.  Certainly, Akamai represents a significant amount of 
> SSL traffic on the Internet, so we want to make sure we future proof 
> our designs.  My not telling you of how the internals work should not 
> be construed that we're not trying to guard against this and other 
> possible changes.  It is simply relaying to you a real world fact 
> without divulging what I can not divulge.

Hi Charlie -

No problems.  I understand the painful master that is NDA.    That said, 
pretend for a minute that all that's left of TLS1.2 in TLS1.3 is the 
version negotiation and basic record format.  Think about the gotcha's 
that might pop up with your stuff the longer the TLS WG twiddles with 
the protocol.  Figure out if you can tell us anything about them.

If you can't - you can't.   Unfortunately, the corollary of  "if you 
can't explain what's wrong, we can't do anything to fix it" probably 
applies.

Mike





>
> *Charlie Gero*
> Senior Principal System Software Engineer
> Team Lead Engineering - Akamai Labs
> 617.444.3940
>
> On Jul 30, 2014, at 4:59 PM, "Michael StJohns" <msj@nthpermutation.com 
> <mailto:msj@nthpermutation.com>> wrote:
>
> On 7/30/2014 12:27 PM, Gero, Charlie wrote:
>> I can't go into details around it at this time.  Suffice to say, we 
>> definitely do rely on the two being split.
> Hi Charlie -
>
>
> If someone said - "we depend on the packet formats to be predictable"
> I'd say they'd have a case for reliance and backwards compatibility.
> Saying that you did something that will break that is totally and
> completely opaque to the on-the-wire protocol spec and expecting the
> protocol spec not to change (assuming proper on-the-wire negotiation to
> describe said changes) seems to be pushing your luck.
>
> That said, the more details you can share, the better chance we have of
> doing something that won't annoy you.  For example, would your system
> break if the master secret were no longer 48 octets?  Would it break if
> the PRF were not based on SHA256?  Would it break if the PRF were a CMAC
> vs an HMAC?
>
> I have no idea where this idea will go.  It may go nowhere, in which
> case you're safe - for now.  It may go into the protocol.  I think if I
> were at akamai, I'd be looking at why this could be an issue, and how to
> remediate it even if it doesn't make it in.  But that's just me.
>
> Mike
>
>
>
>>
>> -----Original Message-----
>> From: Michael StJohns [mailto:msj@nthpermutation.com]
>> Sent: Wednesday, July 30, 2014 11:46 AM
>> To: Gero, Charlie; tls@ietf.org <mailto:tls@ietf.org>
>> Subject: Re: [TLS] Premaster/Master convention
>>
>> On 7/30/2014 11:02 AM, Gero, Charlie wrote:
>>> 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.
>> So you send the master secret from the handshaker machine out to 
>> several other machines which then do what with it?  Couldn't you send 
>> the traffic keys instead?
>>
>> I'm not sure I understand the constraints you're working under. Could 
>> you expand on that?
>>
>> Thanks - Mike
>>
>>
>>> -----Original Message-----
>>> From: Michael StJohns [mailto:msj@nthpermutation.com]
>>> Sent: Wednesday, July 30, 2014 10:57 AM
>>> To: tls@ietf.org <mailto: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 <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>>
>