I don't think it would be sensible to set an upper limit in this case (those lead to regrets in my experience), however, recommending that the value be kept as small as possible seems OK. It's probably redundant advice though.
Since this is extremely transitory state, I sort-of assumed that it would be OK. And it's zero-length during the handshake. Were you planning on having super-constrained devices with post-handshake auth support? On 7 October 2016 at 21:30, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > 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...? >> > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
