On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote:
> 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;
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
