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

[Karthikeyan Bhargavan <[e-mail]>]

> 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

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




> 
>   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=[e-mail] <mailto:bkaduk=[e-mail]>> wrote:
> 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)
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls