Re: [TLS] Heartbeat and padding

[Aaron Zauner <[e-mail]>]

Michael D'Errico wrote:
> Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec.
> due to the random padding?  There is a requirement to add at least 16
> bytes of random padding to every message:
> 
>    struct {
>       HeartbeatMessageType type;
>       uint16 payload_length;
>       opaque payload[HeartbeatMessage.payload_length];
>       opaque padding[padding_length];
>    } HeartbeatMessage;
> 
>    ...
> 
>    padding:  The padding is random content that MUST be ignored by the
>       receiver.  The length of a HeartbeatMessage is TLSPlaintext.length
>       for TLS and DTLSPlaintext.length for DTLS.  Furthermore, the
>       length of the type field is 1 byte, and the length of the
>       payload_length is 2.  Therefore, the padding_length is
>       TLSPlaintext.length - payload_length - 3 for TLS and
>       DTLSPlaintext.length - payload_length - 3 for DTLS.  The
>       padding_length MUST be at least 16.
> 
>    The sender of a HeartbeatMessage MUST use a random padding of at
>    least 16 bytes.  The padding of a received HeartbeatMessage message
>    MUST be ignored.
> 
> 
> Since the recipient MUST ignore the padding, they can't reverse engineer
> the peer's PRNG, so maybe this isn't a problem?
You should ignore it, but you can still recieve it, right?

I was wondering about exactly the same issue a few weeks ago. As far as
I know (and some people familiar with implementations have suggested)
you do not need to pad with CSPRNG here and implementations allegedly do
not do so, I didn't have time to check in codebases of SSL libs though.

Aaron