Re: [TLS] RFC 6066 - Max fragment length negotiation

Peter Gutmann wrote: > Thomas Pornin writes: >> >>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web >>world. This is not necessarily _bad_, but it is likely to leave some people >>unsatisfied (and, in practice, people clinging to TLS 1.2). > > I would

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thomas Pornin writes: >TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web >world. This is not necessarily _bad_, but it is likely to leave some people >unsatisfied (and, in practice, people clinging to TLS 1.2). I would go slightly further and say that

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Tue, Mar 21, 2017 at 7:03 PM, Martin Thomson wrote: > On 22 March 2017 at 12:01, Eric Rescorla wrote: > > The maximum amount of wastage in this case is E_max - E_min where E_min > is > > the minimum amount of expansion of any cipher suite they

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 22 March 2017 at 12:01, Eric Rescorla wrote: > The maximum amount of wastage in this case is E_max - E_min where E_min is > the minimum amount of expansion of any cipher suite they support. Right, I was concerned about the case where this difference is (potentially) large.

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Tue, Mar 21, 2017 at 5:44 PM, Martin Thomson wrote: > On 22 March 2017 at 11:09, Eric Rescorla wrote: > > Couldn't you just use the maximum expansion you support (which > > ought to be 16 for TLS 1.3). > > That leads to the same problem that we're

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 22 March 2017 at 11:09, Eric Rescorla wrote: > Couldn't you just use the maximum expansion you support (which > ought to be 16 for TLS 1.3). That leads to the same problem that we're trying to avoid, namely that your usable space goes through the floor. >> When compression is

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Tue, Mar 21, 2017 at 4:58 PM, Martin Thomson wrote: > On 22 March 2017 at 00:32, Peter Gutmann > wrote: > > I'd earlier thought of suggesting that the record length be the > ciphertext > > length, not the plaintext length, but wasn't sure

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 22 March 2017 at 00:32, Peter Gutmann 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,

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thanks Thomas, inline responses. On 22 March 2017 at 00:15, Thomas Pornin wrote: > Therefore, I propose to replace this paragraph: > > An endpoint that has no limit on the size of data they receive can > set this value to any value equal to or greater than the maximum >

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Tue, 2017-03-21 at 14:15 +0100, Thomas Pornin wrote: > On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote: > > I'd even go so far as to specify it: > > > > https://martinthomson.github.io/tls-record-limit/ > > > > I'll submit an I-D once the blackout ends if people are interested

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thomas Pornin writes: >Maybe there should be some extra wording saying that when a "maximum record >size" was received, with a value less than the protocol-defined limit, then >an endpoint SHOULD strive to use minimal-sized padding in cipher suites that >have a variable-sized

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote: > I'd even go so far as to specify it: > > https://martinthomson.github.io/tls-record-limit/ > > I'll submit an I-D once the blackout ends if people are interested in this. I like this proposal. One comment, though: I think the

Re: [TLS] RFC 6066 - Max fragment length negotiation

...@gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation Thanks Yoav. I am assuming it is true for TLS1.2 also? It would be nice to provide a mechanism for servers to do this as we are trying to run a web server in a constrained IoT end-points with only tens o

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thanks Yoav. I am assuming it is true for TLS1.2 also? It would be nice to provide a mechanism for servers to do this as we are trying to run a web server in a constrained IoT end-points with only tens of KBytes of RAM and SSL/TLS based connection is important.. On Thu, Mar 16, 2017 at 4:48 PM,

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hi Joe, thanks for pointing this out. I will talk to our mbed TLS team to find out what the status of this issue is. Ciao Hannes On 03/18/2017 10:17 AM, Joseph Birr-Pixton wrote: > On 17 March 2017 at 16:01, Hannes Tschofenig > wrote: >> Here are my 5 cents: we

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 18 March 2017 at 20:36, Peter Gutmann wrote: > Incidentally, has anyone else who's implemented this dealt in the weird > omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512, > 1K, 2K, and 4K? In many cases 8K is just what you need, it halves

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 18 March 2017 at 09:36, Peter Gutmann wrote: > Joseph Birr-Pixton writes: > >>With the greatest of respect, mbedtls *doesn't* implement >>max_fragment_length[1], because it doesn't fragment handshake messages as >>required by the spec. Attempts to

Re: [TLS] RFC 6066 - Max fragment length negotiation

Joseph Birr-Pixton writes: >With the greatest of respect, mbedtls *doesn't* implement >max_fragment_length[1], because it doesn't fragment handshake messages as >required by the spec. Attempts to use it with a conforming peer will fail to >handshake. What's the largest

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 16:01, Hannes Tschofenig wrote: > Here are my 5 cents: we implement this extension in our mbed TLS stack With the greatest of respect, mbedtls *doesn't* implement max_fragment_length[1], because it doesn't fragment handshake messages as required by

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hannes Tschofenig writes: >Here are my 5 cents: we implement this extension in our mbed TLS stack and we >consider it quite important for IoT devices that have limited amount of RAM. >The DTLS/TLS profiles for IoT RFC also recommends the use of this extension >and we

Re: [TLS] RFC 6066 - Max fragment length negotiation

Ilari Liusvaara writes: >In fact, in TLS 1.3, all messages except Certificate ones are likely to be >under 2k (or 1k). OK, in that case make the max message size 1K, or 512 bytes, or whatver you need. Also, TLS 1.3 as it currently stands, in a pre-standard draft, may

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thomas Pornin writes: >having some guarantees on non-fragmentations may help some implementations >that are very constrained in ROM size and must stick to the simplest possible >code. It's not the code size, it's attack surface. There have been endless attacks on IP

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 04:37:59PM +0100, Thomas Pornin wrote: > > > Also, in TLS 1.3, certificate messages are considerably more > > complicated. I don't think streaming processing of recommended-to- > > support stuff is even possible. > > Streaming processing is ill-supported and on the

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 04:44:48PM +0200, Ilari Liusvaara wrote: > The mere thought of someone implementing streaming processing in > C scares me. I think BearSSL autogenerates that code. Yes, actual code is in a custom Forth dialect, which is compiled to token-threaded code executed by a C

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 03/17/2017 11:57 AM, Martin Thomson wrote: > This is apparently a big deal for people building little things with > TLS in them. Hannes knows better than I do. On the web, this > extension basically doesn't exist (for the aforementioned reasons, in > part, also because browsers historically

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hi Martin, we suggested it in Section 6 of https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 and Thomas also made a proposal in the same direction not too long ago as well, see https://www.ietf.org/mail-archive/web/tls/current/msg22058.html Ciao Hannes On 03/17/2017 07:24 AM,

Re: [TLS] RFC 6066 - Max fragment length negotiation

Here are my 5 cents: we implement this extension in our mbed TLS stack and we consider it quite important for IoT devices that have limited amount of RAM. The DTLS/TLS profiles for IoT RFC also recommends the use of this extension and we discussed this in the DICE WG and there was no objection

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 02:33:44PM +0100, Thomas Pornin wrote: > On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote: > > However, this then leads to a problem where it doesn't actually solve > > the constrained-client/server issue, if a client asks for 2K max > > record size and the

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote: > Martin Thomson writes: > > >Plaintext records don't have any such limits. I explicitly excluded them. > > Hmm, it's somewhat disguised in the text, technically all records are > "protected records" (if

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote: > However, this then leads to a problem where it doesn't actually solve > the constrained-client/server issue, if a client asks for 2K max > record size and the server responds with a 4K hello then it's going to > break the client even

Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson writes: >Plaintext records don't have any such limits. I explicitly excluded them. Hmm, it's somewhat disguised in the text, technically all records are "protected records" (if you use EMS, everything is at least integrity- protected). So if you mean

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 21:38, Peter Gutmann wrote: > Firstly, do we have much real-world experience in using this extension? From > the TLS-support matrix, it looks like very few implementations support this, > does this mean few people care about it or just that it's

Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson writes: >I'd even go so far as to specify it: > >https://martinthomson.github.io/tls-record-limit/ Some comments... Firstly, do we have much real-world experience in using this extension? From the TLS-support matrix, it looks like very few

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 14:49, Martin Thomson wrote: > The design I would use is much simpler. The extension would carry a > two octet value that is the maximum size of the plaintext that the > endpoint is willing to receive. A client could say 2^14 and that > would allow

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 14:35, Peter Gutmann wrote: > Why is it badly designed? I can guess that some people would prefer to have a > mechanism for client and server to debate endlessly what the most cromulent > fragment size is, but that's about the only thing I can see.

Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson writes: >In this case, max_fragment_length is so badly designed that you can actually >argue that it has utility, but I don't consider that as a good argument for >the general case. Why is it badly designed? I can guess that some people would prefer to

Re: [TLS] RFC 6066 - Max fragment length negotiation

FWIW, this requirement is actually very old, dating back to RFC 3546. It's not unique to TLS 1.2. Note that for all extension types (including those defined in future), the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 11:22, Peter Gutmann wrote: > Is that from actually trying it with clients, or just assuming that > implementations will do what the spec says? I know for certain that NSS explodes. Not from trying, but from knowing that part of the code very well.

Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson writes: >On 17 March 2017 at 10:45, Peter Gutmann wrote: >> In which case it might be time to update the RFC, since there's no obvious >> reason why you can't send it from the server. Can any of the original >> authors >>

Re: [TLS] RFC 6066 - Max fragment length negotiation

On 17 March 2017 at 10:45, Peter Gutmann wrote: > > In which case it might be time to update the RFC, since there's no obvious > reason why you can't send it from the server. Can any of the original authors > provide a reason why it shouldn't be done by the server?

Re: [TLS] RFC 6066 - Max fragment length negotiation

Yoav The constrained end point is server serving web pages to browsers. Nitin > On Mar 16, 2017, at 4:59 PM, Yoav Nir wrote: > > >> On 16 Mar 2017, at 22:52, Nitin Shrivastav >> wrote: >> >> Thanks Yoav. I am assuming it is true for

Re: [TLS] RFC 6066 - Max fragment length negotiation

Nitin Shrivastav writes: >Thanks Peter, seems like this extension is not an option. In which case it might be time to update the RFC, since there's no obvious reason why you can't send it from the server. Can any of the original authors provide a reason why it

Re: [TLS] RFC 6066 - Max fragment length negotiation

Thanks Peter, seems like this extension is not an option. I guess since our server is serving the web pages to browsers, we should be able to predict the max amount of data that will be pushed when user submits the data on the web page and tune the ssl buffer accordingly. > On Mar 16, 2017,

Re: [TLS] RFC 6066 - Max fragment length negotiation

Nitin Shrivastav writes: >We don't have control over the clients in our scenario which are basically >the browsers like Chrome, IE etc. I think a more important question would be "does any browser support this"? Looking at:

Re: [TLS] RFC 6066 - Max fragment length negotiation

> On 16 Mar 2017, at 22:52, Nitin Shrivastav > wrote: > > Thanks Yoav. I am assuming it is true for TLS1.2 also? RFC 5246 *is* TLS 1.2. But it’s true for previous versions and for 1.3 as well. > > It would be nice to provide a mechanism for servers to do this

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hi, Nitin. In section 7.4.1.4 of RFC 5246 it says: An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. So the answer is no. Only the client may request this. Yoav > On 16 Mar 2017, at 21:12, Nitin Shrivastav

[TLS] RFC 6066 - Max fragment length negotiation

Hello, This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question on RFC 6066 Maximum Fragment Length Negotiation section The question i have is whether it is possible for a server to initiate the Max fragment length negotiation. The RFC describes a scenario where a constrained