L83: TLS Session Key Export in gRPC C++

[Vignesh2208]

Relevant Github Issue: https://github.com/grpc/grpc/issues/24944 Relevant PR: https://github.com/grpc/grpc/pull/26812

CC @markdroth, @ctiller

[markdroth]

The number "L82" is already taken by #245. Please use "L83" for this.

[ctiller]

@yihuazhang @ZhenLian @markdroth I don't think I'm sufficiently up to date with the TLS creds model to be an approver here, can someone else take that role?

[yihuazhang]

@ZhenLian, since the new feature will be added to advanced TLS, do you mind taking a look? PLMK if you are busy, I can also take the role.

[ZhenLian]

@yihuazhang Yeah this is in my list, but feel free to take another look if possible. Sorry about the delay - I was busy with perf&intern stuff, etc in the past few weeks.

[ZhenLian]

@markdroth Mark, can I know in general, when do we expect a gRFC to be merged? Do we merge it when the proposed API is implemented, or we merge it when the proposed API become stable? I know here we are waiting for https://github.com/grpc/proposal/pull/205 to get in, but given the recent work to unify the security API, the newly proposed change is unlikely to get implemented throughout the end of this year. That might further defer gRFC(s) like this. There are still some rooms for improvements around Provider and Verifier, but the TlsCredentials and TlsCredentialsOptions themselves are pretty "stable" now. I wonder if we can come up with a way to merge the gRFCs step by step? Maybe I can write the gRFC for the TlsCredentials and TlsCredentialsOptions, and then we can gradually merge some small features, like TLS key exporting, or TLS version selection(which is a feature blocking for a really long time, since last year I think, @matthewstevenson88)? For gRFCs about Provider or Verifier, it's OK to put them in Open state, since they are still not finalized yet. This also helps to keep each gRFC relatively short and staying on one single security topic, which might be easier for future readers to read. What do you think about this idea? @yihuazhang FYI.

[markdroth]

My preference is still to have one single gRFC for the entire TlsCreds API, which we'd want to merge when we get to the point where we're ready to de-experimentalize the API. I think that will make it much easier to see the entire cohesive design in one place.

Note that the above can happen while some features are still experimental; those features would just not be covered in the gRFC and can be added later in a separate gRFC. But we would need to get to the point where the APIs for all of the core functionality of TlsCreds is stabilized and we're ready to commit to those APIs.

In particular, I don't think it makes sense to go forward with any gRFC for TlsCreds without stabilizing our design for the providers and verifiers. That's core functionality that we need to have nailed down, IMHO.