Subject: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Jul 2018 18:00:09 -0500

Hi all,

As I mentioned at the mic today, there is a question that has been
raised about whether it's wise to reuse an existing (TLS 1.2) PSK
directly in the TLS 1.3 key ladder.  At a high level, the reason why one
might want to restrict this is that the security proofs for TLS 1.3 rely
on the pre-shared key being only used with a single key-derivation
function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
key-derivation function, so formally the proofs do not hold.  We don't
currently know of a specifc attack against such reuse, of course, but
perhaps it is prudent to restrict our usage to adhere to the verified
scenarios.

This is somewhat timely, as if we do want to introduce a restriction, it
would ideally be in the form of some text in the TLS 1.3 specification,
which is very nearly done.

It would be good to hear more opinions on this question, particularly
from those who have worked on the formal verification directly.

If I can attempt to summarize some discussion that occurred in the mic
line today, Hannes was surprised that we would care, likening this case
to the regular version negotiation, where we are happy to use the same
certificate to sign messages for both TLS 1.2 and 1.3.  David Benjamin
points out that we explicitly go to the trouble of putting 64 bytes of
0x20 padding at the front of the content that gets signed for
CertificateVerify, to enforce separation between the TLS versions.

My own personal opinion is that we should enforce a domain separation
between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs"
proposal seems like a potential mechanism by which to do so without
doubling the provisioning needs.

-Ben (with no hat)

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 20 Jul 2018 09:29:03 +0200

> doubling the provisioning needs.

I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. 
There is no inherent difference between the two keys types. I could
have deployed TLS with PKI or TLS with PSK. I should be able to upgrade
protocols the same way.

If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should
PSK keys. The current document specifically allows that re-use, and if
you fear that the current document did not take cross-protocol attacks
in mind during design, then let's fix that instead.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2018 02:38:32 -0700

> in mind during design, then let's fix that instead.

The issue is not cross-protocol attacks; it's the reuse of PSKs with
different KDFs, which we don't have any analysis for and which the TLS 1.3
document prohibits.

-Ekr

> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Matt Caswell <[email-masked]>
Date: Fri, 20 Jul 2018 10:43:48 +0100

On 20/07/18 10:38, Eric Rescorla wrote:
> different KDFs, which we don't have any analysis for and which the TLS
> 1.3 document prohibits.

Can you supply the reference for that prohibition?

Thanks

Matt

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Jul 2018 13:43:18 +0300

> Can you supply the reference for that prohibition?

Section 'Pre-Shared Key Extension'. In practicular, the paragraph
starting "Each PSK is associated with a single Hash algorithm." That
one prohibits using PSK associated with a hash with another hash.
However, I did not find prohibition of using PSKs from prior versions
of TLS using SHA-256 as the associated hash (as that is the default).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2018 04:05:30 -0700

> of TLS using SHA-256 as the associated hash (as that is the default).

Right. There's no such text. However, the TLS 1.2 SHA-256 KDF isn't HKDF
(and of course the TLS 1.0 KDF isn't even SHA-256), so we're kind of in an
unclear area.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 20 Jul 2018 13:39:40 +0200

On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > 
> > > This is somewhat timely, as if we do want to introduce a
> > restriction,
> > > it
> > > If I can attempt to summarize some discussion that occurred in
> > the
> > > mic
> > > line today, Hannes was surprised that we would care, likening
> > this
> > > case
> > > points out that we explicitly go to the trouble of putting 64
> > bytes
> > > of
> > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's
> > "Universal
> > > PSKs"
> different KDFs, which we don't have any analysis for

I understand, but as I have already mentioned that argument also
applies for RSA keys which can be used e.g., for RSA encryption under
TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used
with multiple hashes under TLS1.2 while only one under TLS1.3.
TLS 1.3 did not enforce protocol separation for that ugly scenario, so
I wouldn't expect the treatment of PSKs differently.

Said that, I want to clarify that I wouldn't necessarily object to an
improvement the situation for externally established PSKs. The issue I
see is that TLS1.3 already gives a "good enough" solution with re-using 
the key, and I'm afraid we're going to have interoperation issues if
some implementations move to universal psks and some do not, defeating
the purpose of a standard.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2018 05:08:48 -0700

> I wouldn't expect the treatment of PSKs differently.

I will let Karthik speak for himself, but I believe we do in fact have
analysis
for these cases.

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Fri, 20 Jul 2018 08:42:47 -0400

> I wouldn't expect the treatment of PSKs differently.

PSKs are much easier to fix this with than signing algorithms, given that
we don't want to reprovision either to deploy TLS 1.3.

ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash to
mixup, just restricted the set from TLS 1.2. If we left it alone, we'd
still have the same effect. For RSA, you're right that we introduced an
extra pair of algorithms to worry about. The options there are:

(1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. Cost: TLS
1.3 requires reprovisioning RSA keys.
(2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: We
have two algorithms with one key.
(3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1.

(1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine with
either (2) or (3), but the WG chose (2).

With PSKs, I think we can get both. If we consider 1.2 PSKs to be paired
with the 1.2 PRF, we can allocate a new label, and derive a separate thing
to stick in 1.3, and not require reprovisioning. It's basically free, so I
think it makes sense to do it.

(I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is
probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't
think we actually believe SHA256 and SHA384 give related output. It's just
nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256
actually a chance of misbehavior. Perhaps it's worth doing that analysis?)

Of course, I don't actually know what I'm talking about. Opinions from the
formal analysis folks would be great. :-)

> the purpose of a standard.

I think that's the point of deciding this immediate question now, so we can
get some text in the specification. If we decide to fix this, we'd instruct
implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs are configured
and then, once the fixup document is published, implement it and remove the
version logic. This is interoperable at all combinations as version
negotiation runs first.

Personally, I actually don't care much about 1.2 PSKs as I don't work with
anything that uses them. I do care about allowing new protocols to use 1.3
external PSKs cleanly---new protocols can just mandate 1.3 and avoid 1.2,
but the hash rule makes the whole thing unusable and it is unclear whether
1.3 PSKs will be usable in a future 1.4. I figured it'd be easy to patch
the 1.2 issue while I was at it, thus the construction in my draft.

But the exact derivation can be worked out separately, my draft or not. The
immediate question is whether we think 1.2 PSKs should be reusable in 1.3
as-is or whether we should stick a derivation step to separate them.
(Thanks, Ben, for making this thread. I failed to call out the immediate
question in mine and then didn't had time to catch up on it.)

David

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Jul 2018 17:21:04 +0300

> actually a chance of misbehavior. Perhaps it's worth doing that analysis?)

TLS 1.3 does this with PSK:

HMAC(<zeroes>, PSK)

And TLS 1.2 does:

HMAC(<expanded PSK>, <some data>)

(where <some data> actually depends on <expanded psk>). Now, it is
possible that there is second similar block in there, but that uses
the same <expanded PSK>.

However, noteworthy point is that there is only two ways to end up in
situation where the effective key in TLS 1.2 is all zeroes:

1) <expanded psk> is longer than hash block and is preimage of 0.
   Finding such thing is supposed to be infeasible.
2) The PSK is empty. However, the <some data> on TLS 1.2 side is
   not empty in this case (it starts with gunk from HMAC that
   involves at least both randoms). Also, empty PSK is not secure.

The definition of HMAC is:

H(C(key) XOR opad | H(C(key) XOR ipad, data))

Which preserves collision resistance on C(key) and data. Now, C(key)
is not collision resistant. However, the only possible cases where
C(key) can collide are the two above.

So it seems to me that TLS 1.2 and TLS 1.3 compute independent
things from PSK values, in all practical cases.

-Ilari

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 23 Jul 2018 14:02:38 +0200

Hi all,

Couldn't make it to the second TLS session, but I did suggest on the
mailing list a tweak to the universal PSK draft that achieves
compatibility, unambiguity, and is straight-forward to prove secure
formally. (By which I mean prove independent of the security of TLS 1.2,
and thus any hash function it uses, even a pathalogical one.)
https://www.ietf.org/mail-archive/web/tls/current/msg26419.html
In brief I suggest that you transform both the PSK ID and the PSK itself in
such a way that a server that accepts them tacitly acknowledges the upgrade
of the PSK from 1.2 to 1.3.
You can achieve compatibility with a server that doesn't support this by
offering the untransformed PSK ID also, at the cost of a more complex
formal analysis / potentially weaker security.

Regards,

Jonathan

---

From: Matt Caswell <[email-masked]>
Date: Mon, 23 Jul 2018 13:56:17 +0100

On 20/07/18 13:42, David Benjamin wrote:
> I think that's the point of deciding this immediate question now, so we
> can get some text in the specification. If we decide to fix this, we'd
> instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs
> are configured and then, once the fixup document is published, implement
> it and remove the version logic. This is interoperable at all
> combinations as version negotiation runs first.

So, to be clear about this interim proposal:

1) If a client is configured with a 1.2 PSK but not a 1.3 PSK, it should
not provide supported versions, and only negotiate TLSv1.2 or lower. If
it has both then it should supply supported versions and advertise
support for TLSv1.3.

2) If a server is configured with a 1.2 PSK and not a 1.3 PSK it should
only select TLSv1.2 or lower.

3) If a server has separate 1.2 PSKs and 1.3 PSKs should it allow 1.3 to
be negotiated? Presumably "yes" to allow a phased roll out of TLSv1.3 to
clients.

Consider the case after Universal PSKs have been introduced. A client
that has not been explicitly configured for 1.3 PSKs can suddenly start
offering them and will issue a ClientHello containing supported versions
with TLSv1.3 in it. But if it then attempts to connect to a server which
does not support universal PSKs and has been explicitly configured with
separate 1.2 and 1.3 PSKs the server will select TLSv1.3, but then the
connection will fail because the explicit 1.3 PSK configured on the
server is not compatible with the Universal PSK offered by the client.

Or did I misunderstand something somewhere?

Matt

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Jul 2018 15:45:17 +0200

On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote:
> PSKs are much easier to fix this with than signing algorithms, given
> that we don't want to reprovision either to deploy TLS 1.3.
> 
> ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash
> to mixup, just restricted the set from TLS 1.2. If we left it alone,
> we'd still have the same effect. For RSA, you're right that we
> introduced an extra pair of algorithms to worry about. The options
> there are:
> 
> (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption.
> Cost: TLS 1.3 requires reprovisioning RSA keys.
> (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost:
> We have two algorithms with one key.
> (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine
> with either (2) or (3), but the WG chose (2).
> 
> With PSKs, I think we can get both. If we consider 1.2 PSKs to be
> paired with the 1.2 PRF, we can allocate a new label, and derive a
> separate thing to stick in 1.3, and not require reprovisioning. It's
> basically free, so I think it makes sense to do it.

> (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256
> is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I
> don't think we actually believe SHA256 and SHA384 give related
> output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF-
> SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's
> worth doing that analysis?)
> Of course, I don't actually know what I'm talking about. Opinions
> from the formal analysis folks would be great. :-)

I wouldn't expect much from formal analysis here, though in the past
I've been positively surprised. I'd expect "don't mix algorithms", as
with RSA and RSA-PSS.

> I think that's the point of deciding this immediate question now, so
> we can get some text in the specification. If we decide to fix this,
> we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2
> PSKs are configured and then, once the fixup document is published,
> implement it and remove the version logic. This is interoperable at
> all combinations as version negotiation runs first.

> Personally, I actually don't care much about 1.2 PSKs as I don't work
> with anything that uses them. I do care about allowing new protocols
> to use 1.3 external PSKs cleanly---new protocols can just mandate 1.3
> and avoid 1.2, but the hash rule makes the whole thing unusable and
> it is unclear whether 1.3 PSKs will be usable in a future 1.4. I
> figured it'd be easy to patch the 1.2 issue while I was at it, thus
> the construction in my draft.
> 
> But the exact derivation can be worked out separately, my draft or
> not. The immediate question is whether we think 1.2 PSKs should be
> reusable in 1.3 as-is or whether we should stick a derivation step to
> separate them.

The derivation makes sense to be part of the draft. It makes sense to
me the whole draft to be part or referred from TLS1.3.

regards,
Nikos

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Thu, 26 Jul 2018 12:21:59 -0400

I can speak a little to how the reuse of keys will affect existing TLS 1.3 proofs and analyses.

First it is worth noting that most TLS 1.3 proofs do not consider hash function agility, and say nothing about deploying TLS 1.3 in parallel to TLS 1.2 (with some exceptions like [1], [2])
So, the good news is that these proofs do not care much about how PSKs or signature keys are used in TLS 1.2.
The bad news is that this means that, in general, reusing the same keys in 1.2 and 1.3 is insecure.
Even just within TLS 1.3, if we use the same PSK with two versions of HKDF that use different hash algorithms, we would need a strong “joint” assumption on both these hash functions.
Assuming that the HKDF hash algorithm is fixed (either by the standard or for each key), we can then use the Universal PSK trick to specialize the PSK for other parameters (such as hash algorithm used for the TLS transcript).
But from what I understand the HKDF hash algorithm is itself determined by the cipher suite hash algorithm, so I need to think whether the specialisation provides any formal guarantees.

Secondly, TLS 1.3 analyses that account for downgrade attack (like [1],[2]) show that the downgrade countermeasures in TLS 1.3 are sufficient to protect TLS 1.3 sessions, but only under some conditions.
In particular, [2] shows that it is only safe for an endpoint to reuse keys between TLS 1.2 and TLS 1.3 if
(1) even in TLS 1.2, the endpoint only supports PSK-based or signature-based ciphersuites (i.e. no RSA encryption)
(2) even in TLS 1.2, the endpoint only supports “strong” hash functions 
(3) in TLS 1.2 and 1.3, all the hash functions used within signatures and MACs are *jointly* collision resistant (i.e. you cannot easily find b such that H2(b) == H1(a), for different supported hash functions H1 and H2)

In summary, the security proofs for TLS 1.3 require fairly strong conditions on what modes and algorithms of TLS 1.2 can be safely supported by the same client/server.
It is probably worth writing these down as security considerations, and we can quickly discuss this with the academics who did the various proofs.

-Karthik

[1] Downgrade Resilience in Key-Exchange Protocols (IEEE S&P 2016) https://eprint.iacr.org/2016/072
[2] Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate (IEEE S&P 2017)  https://hal.inria.fr/hal-01528752v2/

> On 20 juil. 2018, at 08:08, Eric Rescorla <[email-masked]> wrote:
> 
> Karthik

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jul 2018 10:58:05 -0700

Ben,

Thanks for focusing on this issue.

Chris and I have been discussing an alternative design which we think
is more consistent with the existing structure, which we call PSK
Importers. As with your design, we have an input universal PSK, but
instead of using explicitly as part of the connection, we just use it
as the base key to import a set of new PSKs into TLS.

As with Universal PSKs (UPSKs), each input key is a triplet of
(BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
as used today. To use a UPSK, an implementation takes the set of KDF
hashes it knows about H_i and derives a set of PSKs:

  Hash_i: H_i
  Identity_i: BaseIdentity || H_i
  Key_i: Derived from BaseKey and Identity_i

This gives you a set of keys which you can offer simultaneously on the
TLS connection in independent psk_identity blocks. (Note that the hash
algorithm is what differentiates each derived key.) This is a bit
ugly, but with the current TLS 1.3 ciphers, this basically just means
SHA-256, but even in the worst case it’s probably only 2-3.

The nice thing about this design is that if you know the set of hash
functions, you can just compute all the imported PSKs in advance, and
there’s no need to touch the internals of the TLS stack. This also
means that if you have decided you don’t like old hash X, you don’t
need to use it to compute PSK binders, you just use it do the KDF,
which seems like it has weakersecurity requirements.

Here’s a specific construction, but we’re flexible about the details:

   struct {
       opaque base_identity<1...2^16-1>;
       HashAlgorithm hash;
   } imported_psk_identity;

   UPSKx = HKDF-Extract(0, UPSK)  // UPSK is the input universal PSK
   PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity),
TargetHash.length) // Might need to shorten label

These functions would be executed with the KDF associated with the UPSK,
but produce
a key the size of the desired hash.

This brings us to the question of TLS 1.2. I found Ilari’s analyis
pretty persuasive, so I would suggest we add the following text to the
TLS 1.3 spec:

    TLS 1.3 takes a conservative approach to PSKs by binding them to a
    specific KDF. TLS 1.2 allows PSKs to be used with any hash function
    and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3,
    although both based on HMAC, are very different and there is no known
    way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would
    produce related output, although only limited formal analysis has been
    done. Implementations MAY wish to avoid reuse of keys between TLS 1.3
    and TLS 1.2, or use a key derivation proposal such as [Informative ref
    to this email or a draft].

Other than this, we wouldn’t make any changes to the document.

What do people think?

-Ekr

On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 26 Jul 2018 13:38:35 -0500

> Thanks for focusing on this issue.

Just trying to make sure loose ends get wrapped up before TLS 1.3 goes final...

> Importers. As with your design, we have an input universal PSK, but

(I think you mean David Benjamin's design?)

>     specific KDF. TLS 1.2 allows PSKs to be used with any hash function

(I know it's awkward to write about, but we don't really get away with
pretending that 1.2 1.3 are the only versions in the rest of the document.)

>     to this email or a draft].

I might add "to avoid the risk of using under-analyzed cryptographic constructions"
(or similar), but implicit might be good enough.

> Other than this, we wouldn’t make any changes to the document.

This seems like a good sort of approach to take (that is, make the key derivation
for hash specificity something that happens outside of the TLS mechanics itself),
given the context in which we're thinking about it.

It might be worth going even farther, and including the target TLS version in the
(derived) identities and keys.  Though maybe the negotiation process means that
doesn't actually protect against an attack; I haven't thought it through enough.

Thanks for putting this together,

Ben (no hats)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jul 2018 11:47:25 -0700

> (I think you mean David Benjamin's design?)

Oh, yeah. I originally meant to be responding to davidben and then forgot
to edit
the msg.

> pretending that 1.2 1.3 are the only versions in the rest of the document.)

Fair enough.

> (or similar), but implicit might be good enough.

I like that.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Jul 2018 10:18:20 +0300

> a key the size of the desired hash.

Using HashAlgorithm here does not seem to be great. The problem being
that HashAlgorithm is shadowed by SignatureScheme, which could make
adding a new ciphersuite hash problematic, due to needing to add a
new HashAlgorithm.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 27 Jul 2018 11:07:20 +0200

>        opaque base_identity<1...2^16-1>;

That looks nice, as it allows compatibility with existing psk
implementations.

One improvement could be to have a magic number, to allow easy
disambiguation between an potential existing "raw" (non ascii username
identity), and the new approach.

   struct {
       opaque magic[4]; // 0x544c0103
       HashAlgorithm hash;
       opaque base_identity<1...2^16-1>;
    } imported_psk_identity;

Such a field will also allow further future improvements to that
approach if needed and allow for incompatible changes in draft versions
as the magic serves as version number.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jul 2018 05:00:52 -0700

> adding a new ciphersuite hash problematic, due to needing to add a

That's a reasonable point. Do you have a proposed alternative? We don't
require that you associate a cipher suite with the key unless you want to
do 0-RTT.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Jul 2018 15:49:22 +0300

> require that you associate a cipher suite with the key unless you want to

Well, one could do a new enumeration or pick a canonical ciphersuite
for every hash. Both have maintenance concerns when a new hash is
introduced. OTOH, using HashAlgorithm would not solve those (even if
the thing had not gotten shadowed), since the new hash is likely not
any of the current ones in HashAlgorithm enumeration (the only non-
deprecated algorithm that is not in use as ciphersuite hash is
SHA-512)

The new enumeration would currently only need sha256 and sha384. For
canonical, the first TLS 1.3 ciphersuites for those would be 1301 and
1302 (the first in all TLS would be 003B and 009D). As can be seen from,
this, picking canonicals is a bit yucky.

-Ilari

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 27 Jul 2018 09:43:03 -0400

> hashes it knows about H_i and derives a set of PSKs

To be clear, you’re suggesting that the KDF  attached to an input key could be different from the KDF used within TLS 1.3 itself.
E.g. the KDF here could use HKDF-SHA256 whereas H_i and the hash function in the TLS 1.3 cipher suite could be SHA-384 or whatever, is that correct?

The nice feature of this imported PSK is that it is then completely outside the model of TLS, its just a way of provisioning multiple independent TLS PSKs, where each TLS PSK can presumably only be used with one hash algorithm (and one protocol version?)
If so, this should compose nicely with existing TLS proofs.

-Karthik

>    PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), TargetHash.length) // Might need to shorten label
> 
> These functions would be executed with the KDF associated with the UPSK, but produce
> On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk <bkaduk=[email-masked] <mailto:bkaduk=[email-masked]>> wrote:
> Hi all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jul 2018 08:49:36 -0700

On Fri, Jul 27, 2018 at 6:43 AM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> To be clear, you’re suggesting that the KDF  attached to an input key
> could be different from the KDF used within TLS 1.3 itself.
> E.g. the KDF here could use HKDF-SHA256 whereas H_i and the hash function
> in the TLS 1.3 cipher suite could be SHA-384 or whatever, is that correct?
>

Precisely. In fact, the KDF associated with the UPSK could be some KDF that
TLS doesn't even specify (e.g., a SHA-3 based construction).

> The nice feature of this imported PSK is that it is then completely
> outside the model of TLS, its just a way of provisioning multiple
> independent TLS PSKs, where each TLS PSK can presumably only be used with
> one hash algorithm
>

Yes.

(and one protocol version?)

This is less clear. We'd obviously prefer to allow TLS 1.3 PSKs to be used
with TLS 1.4 if possible (this would require the binders to be compatible).
But we can figure that out if we do 1.4.

Good news!

Do you have any comments on my proposed disclaimer text?

-Ekr

> On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk <
> bkaduk=[email-masked]> wrote:
>
>> Hi all,
>>