Draft: draft-ietf-tls-tls13

Commentary: 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 does n'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 does n'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 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 And 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   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 .
Paragraph (version A):
The presence of padding does not change the overall record size
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.
Paragraph (version B):
The presence of padding does not change the overall record size
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.