Re: [TLS] Premaster/Master convention

Eric Rescorla <ekr@rtfm.com> Wed, 30 July 2014 16:27 UTC

Return-Path: <ekr@rtfm.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 A3E921A0197 for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 LbtMJHKSiUfl for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:27:04 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8221A01DD for <tls@ietf.org>; Wed, 30 Jul 2014 09:27:03 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id n3so7925211wiv.17 for <tls@ietf.org>; Wed, 30 Jul 2014 09:27:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zSeaCQANQCkDZGy3xpwmSN1bWmhWuei+PyISMuPuqu8=; b=RjGt73TRw6YbKRfq8ZKRI/+Gs2fyzxZqyO2zq0L73jdxtzpcYloN/HYkIdvbG+j4Ao 5em+CRFOW23UlGRBuuhLjbWkM1K6bB8cXdJhaJwnzfcyV8s443OfkLS6gv4XAcJd76LP 6LmMyfrvMQwsgxtyA/K67A221UB6DABS+q2C2i+seH2Dgu1GEp3PvfSbd/crZifXe2oI Xppb0ZAGHV8JM3Eb5dh8TuTKgMlzQk9VDoumVCWstfr1XI8jyal78YePNaymomJAIIX3 +SSYeUwT1N3B1C+1Zq2YrDuYA9QxOIbkYbZN2AzPURc/gupd7Su4HDuGGLPNM6NLFnYe mVrA==
X-Gm-Message-State: ALoCoQnmgJWpBjqz3BbbHAbuvX7iS9nQsAvk1+UQNFHyJeRzBBWUsePhfcmTY5zLfzZDAlZwjdru
X-Received: by 10.180.37.77 with SMTP id w13mr7478100wij.78.1406737622237; Wed, 30 Jul 2014 09:27:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Wed, 30 Jul 2014 09:26:22 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <53D91B89.3020506@nthpermutation.com>
References: <53D907B0.3000006@nthpermutation.com> <CABcZeBOCC5-=PVmMyORL7H4BTiixrVWC4TK8=D=sMnqx_Gpcqg@mail.gmail.com> <53D91B89.3020506@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 30 Jul 2014 09:26:22 -0700
Message-ID: <CABcZeBNRvceBdgA16ojEPYAzbAHWcPwTo=C8e26NugoUNkWEJA@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=e89a8f64702144164004ff6ba099
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XSKZMrmP7rnGNBRvExBer4e3uVE
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:27:06 -0000

On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns <msj@nthpermutation.com>
wrote:

>  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"?
>

I mean always have the secret you use for key derivation be
the same size and unstructured and get to it the same way,
regardless of the starting secret.

Thus, I would prefer to stick with the same PMS->MS flow.

-Ekr


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