ImportedIdentity.label

[martinthomson]

Why is this a string and not the protocol version number? It sure would be easier that way.

[martinthomson]

In writing up #16, I realize now that the combination of label and hash is what is being used to identify a KDF. I think that you need to allow for the HashAlgorithm to be replaced by something else in future, or for different applications other than TLS. It might pay to instead reduce the tuple of (tls version, hash) to a single identifier that says tls12_sha256, tls13_hkdf_sha256, which might broaden applicability.

That could be crazy-talk though. Either way, it would be good to understand this better in the abstract so as to make a less ad hoc decision about what is being identified and then how.

[chris-wood]

Why is this a string and not the protocol version number? It sure would be easier that way.

I agree that the info string should probably just be a version. I imagine there will be a use case where someone wants to, say, import with the label "tls1.3 special sauce". In this case, they could KDF their PSK with the the "special sauce" string and then import with the "tls13" label. And at this point, it might as well be the version number. Let's assume this will be done, and the new field will be called "protocol".

So that leaves the question about what to do for the hash algorithm. As you point out, removing the HashAlgorithm dependency would be good for the future. (We have a TODO in the draft to that effect.) So the question then becomes, do we merge whatever this new field is with "protocol," or do we keeep them separate. I don't think we need to merge these for "level matching" or other purposes, so I'm inclined to keep them separate. Thus, how about thee following structure:

struct {
  opaque external_identity<1...2^16-1>;
  uint16 protocol;
  uint16 kdf;
} ImportedIdentity;

Where protocol is a uint16 codepoint, and kdf is an HPKE-like identifier [1] for a KDF, such as HKDF-SHA256 or HKDF-SHA512. We could then define the importer with respect to this KDF, rather than baking in a hard dependency on HKDF.

@davidben, @martinthomson, what do you think?

[1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00#section-7.2

[martinthomson]

That seems reasonable - I think that there is some reason to separate target protocol (and version, as a tuple) from the KDF that is used.

There's a trick in terms of finding the right level of identification to use for the protocol. I suspect that seeding a registry with 0x0304 and 0x0303 is probably the right way to do this. That has the effect of constraining TLS a little in how it chooses version numbers, but I think that's workable.

(As a reminder, in case you thought this was too easy, QUIC uses a 32-bit identifier for versions. We'd need a mapping QUIC. @chris-wood just makes this look simple.)

[chris-wood]

Currently the context binds the info string (or proposed protocol field) to the version of TLS, not to the calling application or protocol (QUIC).

[russhousley]

Do we want to allow the output of the KDF to be anything other that Nh? Right now, L is always Hash.length, which I think i the Nh value associated with the HPKE-like identifier.

[chris-wood]

Right now, L is always Hash.length, which I think i the Nh value associated with the HPKE-like identifier.

Correct! I can't see a reason why we'd want the KDF output to be something different. Do you have a use case in mind?

[russhousley]

If we want this to apply to other contexts, like your special sauce above, it is unclear to me that Hash.length is always the right answer.

[chris-wood]

The point of the importer is to produce a PSK for use in TLS. Why would the context affect the length?

[russhousley]

The discussion of #16 is opening this for other protocol contexts too.

[chris-wood]

@martinthomson @russhousley I made the proposed change in #17. Please have a look!

[russhousley]

Works for me

[chris-wood]

Closed via #18.