Re: [TLS] Inconsistency/redundant length encoding of RenegotiationInfo

Deliberate choice based on an original lack-of-clarity and the
choice the majority of early adopters had taken or preferred.

Nelson Bolyard http://www.ietf.org/mail-archive/web/tls/current/msg04161.html
Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg04176.html

-Martin

Brian Smith wrote:
> 
> An "empty" RegenotiationInfo structure is encoded like this:
> 
>     0xff 0x01 extension_type
>     0x00 0x01 extension_data length
>     0x00      redundant length byte
> 
> Why does RenegotiationInfo needs this redundant length byte? It seems to me
> that it adds nothing except extra code in the implementation--in particular,
> more cases that have to be tested.
> 
> An empty RFC5077 session ticket extension is encoded like this:
> 
>     0x00 0x23 extension_type
>     0x00 0x00 extension_data length
> 
> An empty server name extension is similarly encoded:
> 
>     0x00 0x00 extension_type
>     0x00 0x00 extension_data length
> 
> The extensions from RFC4366--Server Name Indication, Truncated HMAC, Client
> Certificate URL, Trusted CA Key, and Certificate Status extensions are all
> encoded like the RFC5077 extension--that is, without a redundant length
> byte. I think the RenegotiationInfo extension should be encoded similarly,
> because it lets implementations reuse more already-tested parsing code.
> 
> To be clear, I'm not talking about just the case where RenegotiationInfo is
> empty. The redundant length byte seems to be a useless complication in all
> cases.
> 
> Regards,
> Brian
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 