> On 14 Mar 2017, at 5:38, Martin Thomson <martin.thom...@gmail.com> wrote: > > 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.)
Well, I can’t think of a single rational argument in favor of it *not* including the padding, so I guess I agree that it does. If it didn’t include the padding, then any record with length greater than the max_fragment_length would be obviously padded. Why leak that? Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
