SslStream should do a better job of allocating buffer for encryption

[geoffkizer]

See discussion here: #51060

Currently we do two things:
(1) Add a fixed FrameOverhead (now 64 bytes, previously 32) to the input size when allocating a buffer to encrypt into;
(2) Later, in SslStreamPal.EncryptMessage, we will detect a buffer that is too small and allocate a new, temporary buffer to use instead.

This results in two problems:
(1) We are often allocating more than we need to, since the actual header/trailer size is usually less than 64 bytes.
(2) If 64 bytes is not enough, we will silently fall back to a much less performant path, i.e. allocating lots of unpooled buffers. We saw this previously when FrameOverhead was 32 bytes, which is why we changed it to 64.

We know the exactly header and trailer size before we actually do the encryption. We should be able to allocate the exact size needed and remove the unperformant fallback in SslStreamPal.EncryptMessage. This is slightly complicated by renegotiation, but we should be able to just make this work.

@benaadams @wfurt

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See discussion here: #51060

Currently we do two things:
(1) Add a fixed FrameOverhead (now 64 bytes, previously 32) to the input size when allocating a buffer to encrypt into;
(2) Later, in SslStreamPal.EncryptMessage, we will detect a buffer that is too small and allocate a new, temporary buffer to use instead.

This results in two problems:
(1) We are often allocating more than we need to, since the actual header/trailer size is usually less than 64 bytes.
(2) If 64 bytes is not enough, we will silently fall back to a much less performant path, i.e. allocating lots of unpooled buffers. We saw this previously when FrameOverhead was 32 bytes, which is why we changed it to 64.

We know the exactly header and trailer size before we actually do the encryption. We should be able to allocate the exact size needed and remove the unperformant fallback in SslStreamPal.EncryptMessage. This is slightly complicated by renegotiation, but we should be able to just make this work.

@benaadams @wfurt

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[wfurt]

While I see benefits of this, this will get us even more on path of understanding and tracking TLS internal.

[geoffkizer]

Is that bad? Should we be doing the opposite instead?

[wfurt]

I'm not sure if that is bad. We did make a step towards that when we start parsing some TLS frames. No we will need to possibly stay on top of new ciphers and protocol changes. Since there are not frequent that still seem acceptable.

There may be way how to query that after TLS handshakes is done and algorithms set.

If we can ever write non-contiguous chinks to Stream, this may become relevant as we would be able to write header, data and trailer in separate buffers.

[ManickaP]

Triage: this is a follow up, the main problem is solved, this can be done in the future.

[wfurt]

triage: we should look into it if time permits.

[rzikm]

Fixed by #87874