Subject: [TLS] Heartbeat and padding

From: Michael D'Errico <[email-masked]>
Date: Sat, 26 Apr 2014 17:27:41 -0700

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?

Mike

---

From: Hanno Böck <[email-masked]>
Date: Sun, 27 Apr 2014 17:41:49 +0200

On Sat, 26 Apr 2014 17:27:41 -0700
Michael D'Errico <[email-masked]> wrote:

> Not related to Heartbleed(tm), do we need to revisit the Heartbeat
> spec. due to the random padding?

I've been trying to find out any uses for Heartbeat in the past weeks
and have asked lots of people (also on this list). I got lots of "you
could use it for this and that", but not a single pointer to a real
piece of software doing anything with it.

If you have any use case (a real one, not a fantasy one) come back and
talk about fixing it. Until then: The "fix" for all problems with the
Heartbeat extension is to disable it.

tl;dr: TLS became too complex. Getting rid of unused extensions and
features is the first step to fix that.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Watson Ladd <[email-masked]>
Date: Sun, 27 Apr 2014 09:05:07 -0700

> the peer's PRNG, so maybe this isn't a problem?

Two points: Your PRNG shouldn't allow state recovery given a sample,
and if telling people to ignore things that they shouldn't look at
worked, we wouldn't need TLS. That said we need to do some serious
removal of unused options.

Sincerely,
Watson Ladd
>
> Mike
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 28 Apr 2014 14:45:44 +0200

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 09:44:18 -0400

> Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec.

The original use-case was for DTLS, wasn't it?  We only have a single registry for extensions, and that's reasonable since the vast majority of them are applicable to both TLS (TTLS? :) and DTLS.

I think it makes sense to add another column to the extension registry, called "applicability" or something like that with values from the set (both, tls-only, dtls-only) and the default is both.

It's not just out of vengeance, honest! But I think TLS heartbeat should be at least be deprecated in 1.3.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Apr 2014 16:26:09 +0200

> It's not just out of vengeance, honest! But I think TLS heartbeat should be at least be deprecated in 1.3.

Isn't it sufficient to be disabled by default by implementations? Given
its pretty sophisticated use cases for TLS I don't see why it should be
enabled by default. While I had argued against the heartbeat in TLS at
the time it was proposed, we now have it and deprecating it would
actually punish any existing uses of it.

regards,
Nikos

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Apr 2014 16:42:29 +0200

> actually punish any existing uses of it.
I agree. There is no need in having it enabled by default. So if the
application doesn't want it, it just doesn't enable it.

Best regards
Michael

---

From: Bill Frantz <[email-masked]>
Date: Mon, 28 Apr 2014 16:10:09 -0700

On 4/28/14 at 6:44 AM, [email-masked] (Salz, Rich) wrote:

>It's not just out of vengeance, honest! But I think TLS 
>heartbeat should be at least be deprecated in 1.3.

I implemented a heartbeat function in the E language 
communication protocol (which ran on top of TCP). Even the 
abstraction level I implemented it at, it was too far away from 
the application level to allow reasonable values for the 
associated frequency and time out.

IMNSHO, the details of the heartbeat function should be 
specified very close to the application user. Only at that level 
can rational decisions be made about how often to heartbeat and 
with what timeout.

My vote goes to eliminating it from TLS.

I'l like to hear arguments on why it should continue to be in DTLS.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032

---

From: Richard Hartmann <[email-masked]>
Date: Tue, 29 Apr 2014 01:29:01 +0200

On Apr 29, 2014 1:10 AM, "Bill Frantz" <[email-masked]> wrote:

> IMNSHO, the details of the heartbeat function should be specified very
close to the application user. Only at that level can rational decisions be
made about how often to heartbeat and with what timeout.

Agreed. It feels very compressy and should be done higher up.

> My vote goes to eliminating it from TLS.

+1

Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 23:57:01 +0000

On Mon, Apr 28, 2014 at 04:10:09PM -0700, Bill Frantz wrote:

> IMNSHO, the details of the heartbeat function should be specified very close
> to the application user. Only at that level can rational decisions be made
> about how often to heartbeat and with what timeout.
> 

Some applications don't have NOP messages.  If one wants to detect
remote disconnect without sending an application level message, or
to keep connection state alive across a stateful firewall, a
heartbeat can be useful, even over TCP.

However, a heartbeat over TCP does not require any payload or
response.  It can be a record-layer message with a zero-length
payload that elicits no response at all.  This gets no cryptographic
protection, but that just makes it cheaper and safer.

Of course such a NULL heartbeat would be very different from the
DTLS case and would have to be specified separately for TLS.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 20:37:07 -0500

> Agreed. It feels very compressy and should be done higher up.

That's definitely something to consider before rejecting the proposal to remove.

My take is that "keepalive" may well belong at the application, but
PMTUD doesn't.  Or at the very least that PMTUD needs to be done in a
reusable way or it won't get done at all if you punt it to the app
layer.

Removing PMTUD could damage the network.  E.g., apps might resort to
sending the smallest payload they can reliably get to work, which
would increase overhead significantly.  For high performance computing
it would mean having to specify PMTU in configuration.

Now, what information can leak from keepalives?  What about PMTUD?

Clearly one thing that leaks is that an otherwise-idle device is still
online.  Anything else?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 20:42:58 -0500

> protection, but that just makes it cheaper and safer.

Arguably even a TCP application with keepalives might want to keep
PMTUD going on idle connections (sending large keepalives from time to
time to keep the PMTUD info fresh) so that when they get busy they go
fast, but that might be significantly wasteful unless also coupled
with an exponential idle backoff.

But, sure, as to TCP I think we can remove the variable-length payload
heartbeat.

I'm somewhat concerned by having too many special case differences
between DTLS and TLS though.  We've already seen a mistake that meant
that DTLS Hellos cannot carry extensions.

Nico
--