Re: [TLS] Heartbeat and padding

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 28 April 2014 14:42 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 E99D11A0792 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 07:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] 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 sD7hyDOIzxcy for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 07:42:32 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9111A0564 for <tls@ietf.org>; Mon, 28 Apr 2014 07:42:31 -0700 (PDT)
Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 01B991C104668; Mon, 28 Apr 2014 16:42:29 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com>
Date: Mon, 28 Apr 2014 16:42:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4A6A311-69AE-4F42-9668-BBDCA3E873AF@lurchi.franken.de>
References: <535C4EFD.7030608@pobox.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-miVRMDv6bOsHigRPH0AUnS6XQk
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Heartbeat and padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 14:42:35 -0000

On 28 Apr 2014, at 16:26, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

> On Mon, 2014-04-28 at 09:44 -0400, Salz, Rich wrote:
>>> 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.
> 
> 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.
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
> 
> regards,
> Nikos
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>