On Tue, Mar 14, 2017 at 11:10:54AM +0200, Yoav Nir wrote: > > > 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?
Actually, even worse, then the padding would require extra memory, which the endpoint presumably does not have. If you limit padded plaintext length to 513 bytes (the minimum needed for 512 byte plaintext), with current ciphers, the record payload is at most 529 bytes (16 byte tag is added). Thus, you can receive the record into 529 byte buffer and decrypt in place. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
