Re: [TLS] TLS 1.3 Key Schedule

Eric Rescorla <ekr@rtfm.com> Fri, 04 September 2015 16:13 UTC

MIME-Version: 1.0
In-Reply-To: <D2BE6707-1D2D-472B-8367-040486D202A3@vigilsec.com>
References: <581ED6DF-2D2B-4B74-92F0-F4CBEDF565B0@vigilsec.com> <CABcZeBPnUesZE4Tr8ek4aFXmio4epCjivUTHgU++GQ8Uc5b16g@mail.gmail.com> <D2BE6707-1D2D-472B-8367-040486D202A3@vigilsec.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 04 Sep 2015 09:12:30 -0700
Message-ID: <CABcZeBO8DiVT1FW5Va0V-W_ztJWAZfZJLue=R23yiQOpHwbxkQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="f46d04426e20ffbe50051eee2ce1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rbKBtroKwj6vGC_mZCwVY3kftTg>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 Key Schedule
Precedence: list

On Fri, Sep 4, 2015 at 8:58 AM, Russ Housley <housley@vigilsec.com> wrote:

> Eric:
>
> I looked at Hugo's message in the context of the table in Section 7.1:
>
>      Key Exchange            Static Secret (SS)    Ephemeral Secret (ES)
>      ------------            ------------------    ---------------------
>      (EC)DHE                   Client ephemeral         Client ephemeral
>      (full handshake)       w/ server ephemeral      w/ server ephemeral
>
>      (EC)DHE                   Client ephemeral         Client ephemeral
>      (w/ 0-RTT)                w/ server static      w/ server ephemeral
>
>      PSK                         Pre-Shared Key           Pre-shared key
>
>      PSK + (EC)DHE               Pre-Shared Key         Client ephemeral
>                                                      w/ server ephemeral
>
> If I understand Hugo's message correctly, he is saying that in the second
> row, the SS must be part of the key derivation.  I think we need to
> consider the bottom row as well.
>
> It seems to me that using the master_secret capture the benefits of both
> the SS and the ES.  This meets Hugo's requirement for the second row, and
> gets the benefits of the ephemeral values for the bottom row.
>

I don't think you are reading that correctly. The point is that in the case
where SS
is authenticated (e.g., a PSK or a static DH), then the Finished MAC
authenticates
the ServerKeyShare. If you include ES in the Finished key, then you are
using ES to authenticate ServerKeyShare, which apparently makes analysis
harder.

-Ekr




Russ

>
>
> On Sep 4, 2015, at 11:33 AM, Eric Rescorla wrote:
>
> See:
> http://www.ietf.org/mail-archive/web/tls/current/msg17184.html
>
> On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley <housley@vigilsec.com> wrote:
>
>> In Section 7.1, the document says:
>>
>>      4. finished_secret = HKDF-Expand-Label(xSS,
>>                                             "finished secret",
>>                                             handshake_hash, L)
>>
>>      5. resumption_secret = HKDF-Expand-Label(master_secret,
>>                                               "resumption master secret"
>>                                               session_hash, L)
>>
>> Why don't we use the master_secret in both the finished_secret and the
>> resumption_secret formula?
>>
>> Russ
>>
>
>

[TLS] TLS 1.3 Key Schedule Russ Housley
Re: [TLS] TLS 1.3 Key Schedule Eric Rescorla
Re: [TLS] TLS 1.3 Key Schedule Russ Housley
Re: [TLS] TLS 1.3 Key Schedule Eric Rescorla