expose export_keying_material from rustls

[kwantam]

This PR adds support for the export_keying_material method from rustls. Specifically:

• adds a trait, proto::crypto::ExportKeyingMaterial, that can be implemented on a proto::crypto::Session. I did this rather than implement it as part of Session because future crypto impls might not provide this functionality. Of course, can move it to Session if that would be better.

• implements ExportKeyingMaterial for proto::crypto::rustls::TlsSession, which calls the corresponding method on the rustls Session object.

• implements export_keying_material method on quinn::Connection<S> where S: ExportKeyingMaterial, which is just plumbing.

• tests export_keying_material in both proto and quinn.

To test this, you'll need to point to the current main branch of rustls in quinn and quinn-proto. You'll also need to point to a local copy of rustls-native-certs that pulls in the main branch of rustls.

Merging this is blocked on rustls and rustls-native-certs updating.

closes #834

[kwantam]

(test failures expected until rustls is updated)

[djc]

Let's make it part of Session for now, we can split it later if an implementation that doesn't provide keying material comes along. Also, please update rustls to a pinned upstream commit that includes the necessary support (in all crates that depend on it).

[kwantam]

OK, pushed the following:

• 6344f23 makes export_keying_material part of the Session trait.

• 1989122 pins all crates with a transitive dependency on rustls. In some cases this required forking the upstream repo and pinning to a rev of the fork with a correctly updated Cargo.toml. I checked that all of these pins were actually necessary, and unfortunately it appears that they are.

All tests pass on my machine. I will investigate the test failure. Failures were just nightly/stable discrepancies; fixed now.

[djc]

Looks pretty good to me. I'm a bit on the fence about the associated error type, which seems overly specific, but I haven't thought of a great alternative yet. @Ralith, what do you think of these patches?

(FYI, I think all of these commits can be squashed, since they're largely not independent.)

[kwantam]

I suppose the alternative is to conver that error into... a TransportError, maybe?

Happy to squash. Would you like me to do it now, or after @Ralith reviews? Also, should I leave the edits to the Cargo.toml files in a separate commit to make them easier to revert?

[djc]

Squashing isn't urgent, I can do it when merging to master, too. I think we can leave the edits to Cargo.toml files, we've done it before for other upstream changes we wanted.

[Ralith]

Apologies for the delay weighing in here. The error question is interesting. It looks like rustls only generates an error if too much data is requested (see https://github.com/ctz/rustls/blob/main/rustls/src/key_schedule.rs#L362). If we can't think of any other possible errors, I'd prefer to just bake in that semantic (either with an error ZST or just by using Option) and avoid the associated type.

[kwantam]

Thanks for the review, @Ralith! I've addressed your comments other than the one about the error.

As far as I can tell you're right about the error. Would you like me to remove the associated type and create a zero-sized ExportKeyingMaterialError type instead?

[djc]

Yup, that sounds right.

[kwantam]

👍 done!

[djc]

LGTM!

[Ralith]

CI failure looks spurious.