On Fri, Jul 27, 2018 at 05:00:52AM -0700, Eric Rescorla wrote:
> On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara <ilariliusva...@welho.com>
> wrote:
>
> > On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> >
> > > 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.
> >
> > 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.
> >
>
> 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.
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
