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.
ietf.org> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
