Re: [TLS] Heartbleed / protocol complexity

["Manger, James" <[e-mail]>]

> Standard IDL + standard encoding + tooling == this type of problem
> mostly goes away and it's easier to test and fuzz test unit
> components.
>
> TLS has an ad-hoc IDL and encoding, and it IIUC doesn't adhere to its
> own conventions tightly enough that we could now standardize a
> compatible IDL+encoding and develop tooling for it.
>
> To all who have ever poo-poo'ed ASN.1 and friends I now say: you've
> definitevly lost the argument.  If you don't like one IDL, use
> another, or develop a new a new one.

I agree Nico.

The heartbeat message involved in this bug is specified in RFC6520 "TLS and DTLS Heartbeat extension" as:

   struct {
      HeartbeatMessageType type;
      uint16 payload_length;
      opaque payload[HeartbeatMessage.payload_length];
      opaque padding[padding_length];
   } HeartbeatMessage;

I think the exact same bytes on the wire would be achieved with the following alternative.

   struct {
      HeartbeatMessageType type;
      opaque payload<0..2^16-1>;
      opaque padding[padding_length];
   } HeartbeatMessage;

Explicitly indicating a variable-length field with <0..2^16-1> means the a value starts with a length.
I wonder is this change would have made a difference? Do most implementations support variable-length fields automatically with some lower-layer bounds checks? Or do most implementations leave this to heartbeat-specific code?

--
James Manger