IETF Logo Mail Archive

Re: [TLS] Heartbeat and padding

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 28 April 2014 14:26 UTC

Return-Path: <nmav@redhat.com>
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 E21E01A0A20 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 07:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level:
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_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 ER4swX72zuaS for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 07:26:14 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E380C1A047E for <tls@ietf.org>; Mon, 28 Apr 2014 07:26:13 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3SEQCLX010857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Apr 2014 10:26:12 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3SEQ9Ii004272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 10:26:10 -0400
Message-ID: <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Mon, 28 Apr 2014 16:26:09 +0200
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com>
References: <535C4EFD.7030608@pobox.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4ctLOzqM2RTn0d0szOEpG6qaJuk
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:26:19 -0000

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.

regards,
Nikos

v2.23.0 | Report a Bug | By Email