Re: [TLS] Heartbeat and padding

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 28 April 2014 23:57 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7B1A6F17 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 16:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocR544tfaUqK for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 16:57:03 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F01A883C for <tls@ietf.org>; Mon, 28 Apr 2014 16:57:03 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E6672AB09B; Mon, 28 Apr 2014 23:57:01 +0000 (UTC)
Date: Mon, 28 Apr 2014 23:57:01 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140428235701.GL27883@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> <r422Ps-1075i-54C354189F5E4575A21D231C89CC8B57@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <r422Ps-1075i-54C354189F5E4575A21D231C89CC8B57@Williams-MacBook-Pro.local>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2qH0l7dULQMH1uAatRo1fThKkBQ
Subject: Re: [TLS] Heartbeat and padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 23:57:05 -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.
> 
> My vote goes to eliminating it from TLS.

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.