Martin,
Which of these two derivation schemes are you proposing?
Are you assuming that all uses of the exporter_secret are known at the end
of
the handshake? If not, you still need to keep an exporter_secret beyond the
handshake.
Master Secret
|
|
+-----> Derive-Secret(., "exporter master secret 1",
| ClientHello...Server Finished)
| = exporter_secret_1
|
+-----> Derive-Secret(., "exporter master secret 2",
ClientHello...Server Finished)
= exporter_secret_2
Or:
Master Secret
|
|
+-----> Derive-Secret(., "exporter master secret",
ClientHello...Server Finished)
= exporter_secret
|
+-----> Derive-Secret(., "exporter secret
1",
| what_exactly)
| = exporter_secret_1
|
|
+-----> Derive-Secret(., "exporter secret
2",
what_exactly)
= exporter_secret_2
(I wrote "what exactly" since I am not sure what do you plan to include
there.)
Regarding Ilari's comment on HKDF pairings, I have said that an Extract
operation needs to always be followed by an Expand operation, but an expand
operation may be followed by an expand operation. The point is that the
output
of Expand is (typically) intended as a key to another cryptographic
function.
Such function can be HKDF-Expand itself (which is just a specific
implementation
of a variable-length input/output PRF).
Thus, both of the above possible derivations are OK from the point of view
of HKDF.
Hugo
On Fri, Feb 24, 2017 at 12:40 AM, Martin Thomson <martin.thom...@gmail.com>
wrote:
> On 24 February 2017 at 16:01, Sean Turner <s...@sn3rd.com> wrote:
> > So this isn’t entirely novel right I mean we did something similar wrt
> other key schedules?
>
> I certainly hope it isn't novel. I'm just applying the same
> technique: keep independent keys independent.
>
> On 24 February 2017 at 16:09, Felix Günther <guent...@cs.tu-darmstadt.de>
> wrote:
> > just to clarify: you add an additional HKDF.Expand step, not
> > HKDF.Extract, right?
>
> Yes, you are right, I should have said expand. You need to use expand
> to get the label-based separation on type.
>
> I don't know how I got confused about that. If we need to maintain
> extract and expand in pairs (as we have already been burned by), then
> I will defer to cryptographers on that.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
