Clarify empty context vs. no context for exporters

[davidben]

I've always thought this feature of RFC 5705 was ridiculous, but the empty string context and missing context are treated as distinct inputs and give distinct keys. TLS 1.3 claims to implement the same interface, but doesn't talk about the no context case.

We should do one of:

• Add some distinguisher like "0" for no context and "1 || context_value" otherwise.
• Declare that "no context" and "empty context" are, from now on, the same. Mention this in the spec explicitly.
• Declare that "no context" is no longer a valid input and should fail. Mention this in the spec explicitly.

[davidben]

I don't care much and would be content with any of these. The first one is if we prefer to keep the interface 100% the same. The second is if we think "no context" is dumb but don't want to add a failure case. The third is if we think "no context" is dumb and think adding a new failure case is preferable to risking two previously distinct inputs becoming the same.

[ekr]

I think I like version #1, but I don't much care.

PRs wanted.

[davidben]

Oh, I guess there's also option 4, but it makes me sad: Bleed the "no context" mode all the way into HKDF-Expand-Label and say HKDF-Expand-Label can have no hash value. Then you omit the field in HkdfLabel, length prefix and all.

Nick pointed out that 2 or 3 are only a problem if someone uses both options with the same label. And if we believe the IANA registry, there's not all that many labels, so we could also check and see if anyone cares about "no context".

Anyway, happy to put together a PR for whichever version. Is there a TLS-spec-idiomatic way to do a distinguisher? 0 and 1 fine or should it be something sillier? Could also do no context => empty string and context => "\0" || context.

[ekr]

@davidben OK, I think I'm persuaded by Nick's point. Someone needs to audit all the exporters and see if any of them can be used both ways. If not, I think we could get away with options 2 or 3.

[kaduk]

Is anyone expecting to be "someone"? Maybe we should mention the need on the list and/or ask for the chairs' help...

[ekr]

Sure, unless someone wants to volunteer here. Otherwise, it will eventually be me, I guess

[ekr]

I've gone through all the IETF exporter definitions and none of them seem to use both a missing and zero-length context. So I suggest we just declare them to be the same. @davidben OK with you?

[ekr]

Note, I didn't go through the non-IETF definitions, but those guys are on their own

[davidben]

SGTM