Hi Martin, this may be an implementation specific issue but some of the parameters I have to keep in memory while others I "only" have to parse. In some cases the embedded implementation also has control over the number of parameters being included in a message (which is useful for bandwidth reasons as well).
Ideally, I would prefer to have the length of a field somehow relate to the content. Going through all the parameters and re-evaluating whether the size is indeed appropriate might be a good idea. Ciao Hannes PS: For the reason that embedded devices don't have an endless amount of RAM the max_fragment_length extension was introduced and in https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 we suggest to also apply this concepts to lightweight TLS server implementations. On 10/07/2016 11:59 AM, Martin Thomson wrote: > On 7 October 2016 at 20:45, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: >> the problem is that with embedded implementations you need to be >> prepared to receive this amount of data when the specification says so. > > How are you managing 65k session tickets, extensions, cipher suite > lists, supported group lists, etc...? >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
