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, Yoav Nir <ynir.i...@gmail.com> wrote: > 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 <nitin.shrivas...@broadcom.com> > wrote: > > 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 client can initiate this but in our product the server is very > tightly constrained on memory and we want to reduce the memory used for SSL > connections by forcing the clients to use reduce fragment length. We don't > have control over the clients in our scenario which are basically the > browsers like Chrome, IE etc. > > Thanks, > Nitin > ___ > 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
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 <ynir.i...@gmail.com> wrote: > > >> On 16 Mar 2017, at 22:52, Nitin Shrivastav <nitin.shrivas...@broadcom.com> >> 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 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.. > > I don’t get if you mean that the constrained end-point is the client or the > server. But either way, both sides can be configured to use small records. > You only really need this extension when you both have large amounts of data > (so large records would be used without this extension) and the server is a > generic web server that responds to both constrained and non-constrained > devices. > > But even in that case, adding the extension to the ClientHello should not be > infeasible. > > Yoav > >>> On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <ynir.i...@gmail.com> wrote: >>> 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 <nitin.shrivas...@broadcom.com> >>>> wrote: >>>> >>>> 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 client can initiate this but in our product the server is very >>>> tightly constrained on memory and we want to reduce the memory used for >>>> SSL connections by forcing the clients to use reduce fragment length. We >>>> don't have control over the clients in our scenario which are basically >>>> the browsers like Chrome, IE etc. >>>> >>>> Thanks, >>>> Nitin >>>> ___ >>>> 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
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, at 7:18 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > > Nitin Shrivastav <nitin.shrivas...@broadcom.com> 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: > > https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations > > it seems like the answer is mostly "no". > > Peter. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[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 client can initiate this but in our product the server is very tightly constrained on memory and we want to reduce the memory used for SSL connections by forcing the clients to use reduce fragment length. We don't have control over the clients in our scenario which are basically the browsers like Chrome, IE etc. Thanks, Nitin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
