> 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 > <mailto: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 >> <mailto: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 <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls >> <https://www.ietf.org/mailman/listinfo/tls> > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
