When we added padding to TLS 1.3, we created an ambiguity with the max_fragment_length extension.
Does the limit apply to len(TLSInnerPlaintext) or does it apply to len(TLSInnerPlaintext.content) (i.e., TLSPlaintext.length)? That is, does is include the padding and content type, or not? Including the padding would recognize the limitations apply to handling large blobs of encrypted data (see earlier email from Thomas Pornin). That would be my preference. I think that we need to say that though. I guess the second-order question is whether to roll RFC6066-bis or patch these things in TLS 1.3 directly. (BTW, RFC 6066 is quite poor. It's not very precise in identifying what it is talking about, it also describes a negotiation design unlike anything else in TLS, one that can't be extended ever.) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
