On Tue, Mar 21, 2017 at 4:58 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> On 22 March 2017 at 00:32, Peter Gutmann <pgut...@cs.auckland.ac.nz> > wrote: > > I'd earlier thought of suggesting that the record length be the > ciphertext > > length, not the plaintext length, but wasn't sure if there'd be much > support > > for it. > > Yep, you thought right. I considered the same thing, investigated > what it would take to implement and found that it would be awful. I don't feel strongly about this, but... > The > code that deals with record splitting doesn't know anything about the > specific cipher suite right now. It would have to be taught about the > expansion, because without that information it would potentially send > a packet for encryption and then discover that it got too big in the > process and start over. Couldn't you just use the maximum expansion you support (which ought to be 16 for TLS 1.3). > When compression is enabled, I can't imagine > what it would do. > I feel like we could ignore this, and just say "don't do compression" -Ekr Implementing a limit on pre-encryption data turns out to be pretty > trivial, because you change a constant (2^14) into a variable > (record_size_limit). > > You are right that choosing the encrypted size makes setting the value > easier, but that moves the effort to the wrong place. The constrained > device is the one that cares about this, so it can be the one to spend > the effort choosing the right value. Move the effort somewhere else > and you will find that fewer non-constrained devices will bother > implementing the extension. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
