Proposal: do not establish session in identity handshake about xtt-spec

[zanebeckwith]

The main reason I had for provisioning session keys during the identity handshake was for the users who want full unlinkability: run an identity handshake with random-base DAA for each session (or even each message).

I don't know how interesting such a use case would be for anyone, though. For Industry 4.0, anonymity and unlinkability are probably of zero interest. But for situations where personal data is being moved, they might be much more interesting.

[drbild]

That's right - jogging my memory. (I'm working through the protocol description, looking for parts I wish were simpler.)

Given the IoT landscape today, I expect that per-message unlinkability wouldn't be used for many years. Nothing precludes a future version of the protocol from supporting keys/data in the provisioning handshake. Thus, I'm leaning towards removing it. Keep the protocol as simple as possible for the 80% use-case today, but compatible with future backward-compatible support for these features.

I think it's important that support was designed in, to ensure that future support is possible. And in fact, given that we have the design, we should document in an appendix what the future protocol extension would look like. But in the interest of reducing complexity, it would be good to remove the "we're not sure anyone wants this" features for now.

Thoughts?

[zanebeckwith]

After going over multiple ways of altering the protocol to make it clearer while still allowing session and id provisioning, I think I'm on your side.

I would really prefer to not push off fundamental questions (when is this secret material created?) to future versions, just because version negotiation in TLS is so nasty.

But, I agree that it's confusing, and all the variants I could come up with still have too many "if this, then...".

So, it's frustrating, because I feel like a clean, straight-forward version of the protocol is so close, but I'll make the two handshakes completely separate. Agreed that there's no point in making the common case complex for the sake of a possible future case.