Looks very interesting! The main branch is currently targeting 0.24 so I think we'd prefer to avoid duplication in favor of tweaking existing API.

Codecov Report

❌ Patch coverage is 63.22314% with 89 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.52%. Comparing base (f96be2c) to head (c831ad4).

@@            Coverage Diff             @@
##             main    #2698      +/-   ##
==========================================
- Coverage   94.87%   94.52%   -0.35%     
==========================================
  Files          95       95              
  Lines       21794    22033     +239     
  Branches      614      616       +2     
==========================================
+ Hits        20676    20826     +150     
- Misses        992     1081      +89     
  Partials      126      126              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for the feedback! That makes perfect sense.

I’ve been exploring a few ways to adjust the MessageEncrypter API so implementors can optionally take more control over their encryption data path without introducing unnecessary complexity or bloat to Rustls.

Once I’ve worked through the details, I’ll open a separate design discussion issue for the MessageEncrypter trait so we can agree on the right direction before committing to any specific changes.

Sounds great! FWIW, we already greatly appreciate the clear PR description and clean commit history.

Hi @djc, thanks again for the feedback! I wanted to clarify a couple of things before continuing further:

• I'm assuming there's a requirement to avoid breaking changes to the MessageEncrypter trait to maintain compatibility with third-party crypto providers. Is that correct?
• You mentioned preferring API changes over duplication. Could you clarify which duplication you were referring to?
  • There is duplication in the aws-lc-rs/ring provider logic that I can easily resolve (we can concisely write encrypt in terms of encrypt_into)
  • There's also duplication in the sense that the encrypt_into method introduces a parallel data path (PrefixedPayloadBorrowed, OutboundOpaqueMessageBorrowed, RecordLayer::encrypt_outgoing_into) that mirrors the existing encrypt flow

• I'm assuming there's a requirement to avoid breaking changes to the MessageEncrypter trait to maintain compatibility with third-party crypto providers. Is that correct?

No -- the main branch currently represents rustls 0.24, which will be allowed to break any and all public API as we're moving towards a rustls 1.0 release with a long-term stable API. So, unless you have requirements where you'd like to use these changes with rustls 0.23.x, we would prefer to optimize the API and avoid duplication for 0.24.x releases. (We can also publish 0.24.0-alpha releases if that helps you -- and these should be of high quality except for increased API churn -- although I'm not sure we want to do so for a whole bunch of downstream dependencies, like tokio-rustls and hyper-rustls.)

• You mentioned preferring API changes over duplication. Could you clarify which duplication you were referring to?
  • There is duplication in the aws-lc-rs/ring provider logic that I can easily resolve (we can concisely write encrypt in terms of encrypt_into)
  • There's also duplication in the sense that the encrypt_into method introduces a parallel data path (PrefixedPayloadBorrowed, OutboundOpaqueMessageBorrowed, RecordLayer::encrypt_outgoing_into) that mirrors the existing encrypt flow

I mainly meant the latter, though in general I think we'd prefer to avoid duplication where that semantically makes sense.