Change:
The TLSPlaintext size is at most 2^14, so the TLSInnerPlaintext must be at least one more to fit the content type. This matches with the end of the record payload protection section.
Nice catch! We also misread that and applied the check to the wrong end to begin with, but the +1 seems a good idea anyway. Just seems generally simpler if TLS 1.3 doesn't have a pesky version-specific -1 in figuring out how much data can fit in an outgoing record.
Would be nice to have a new test in bogo that checks for rejection of TLSPlaintext having a size of 2^14+2 (or 2^14+1 in case of TLS 1.2).
Yup, will certainly add a test when we fix it. (Though I'll wait for this PR to either go in or be rejected just to have a ruling on whether we should have a +1 in there.)
So, if we go with 2^14+1 for sizeof(TLSInnerPlaintext), that is fine. That means that you can (absent padding) expect to be able to send 2^14 octets in every record, across every TLS version. The issue that this causes is one for the record size limit draft. The valid maximum for that will be 2^14 in TLS 1.2 and earlier, but 2^14+1 in TLS 1.3. That's OK, but I'll need to change that draft to make that observation. We already need to allow for larger values in case an extension expands the record size, so this will be a good test for that code. It's also going to be lots more annoying to write the cross-checking in code, but that is just how things go.
I had been using the text in : But the text in the very last sentence of says: Which doesn't really make sense. TLSPlaintext includes the record header as well as the encrypted data. I suppose that this is accurate if it means , but I misread this as the entire length of the structure. That's a minor point. TLSInnerPlaintext can be at most 2^14 (as defined in Section 5.4), which leads to a different limit of 2^14-1 for URL Should we instead say that 2^14+256 is the limit and the AEAD expansion is 256 octets instead of 255? Leading me to think that something along these lines is what should go in Section 5.2: Or something like that.
See
Fixed
See URL And URL Section A.4.2 says: It should say: The definition in Section 7.4.4 (which includes the "supportedsignaturealgorithms" field) is the correct one (confirmed by Eric Rescorla on 2009-02-27) The supportedsignaturealgorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).
This change conflates two things: an editorial fix for "MUST not" instances, and the +1 tweak. These are both OK though, and I think that this is the right answer to the problem.

Discussion:
The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication post-handshake- <del> authentication.  Servers MUST not send a post-handshake </del> <ins> authentication.  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension.

connection with an "unexpected_message" alert. The presence of padding does not change the overall record size <del> limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14 octets.  If the maximum fragment length is reduced, as for example by the max_fragment_length extension from RFC6066, then the reduced limit applies to the full plaintext, including the padding. </del> <ins> limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets.  If the maximum fragment length is reduced, as for example by the max_fragment_length extension from RFC6066, then the reduced limit applies to the full plaintext, including the content type and padding. </ins> Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification.  If