On 14 Mar 2017, at 13:04, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. > Seems we’re in agreement. So how about modifying the sixth paragraph in section 5.4? OLD: The presence of padding does not change the overall record size limitations - the full fragment plaintext may not exceed 2^14 octets. NEW: The presence of padding does not change the overall record size limitations - the full fragment plaintext may not exceed 2^14 octets. If the maximum fragment length is reduced by the presence of the max_fragment_length extension from [RFC6066] then the reduced limit applies to the full plaintext, including the padding. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
