Re: [TLS] DTLS RRC and heartbeat

Hanno Böck <hanno@hboeck.de> Thu, 21 October 2021 14:30 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C163A172A for <tls@ietfa.amsl.com>; Thu, 21 Oct 2021 07:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.685
X-Spam-Level: **
X-Spam-Status: No, score=2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_BULK_SIG=1.774, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 UIQ_f6fUCFbE for <tls@ietfa.amsl.com>; Thu, 21 Oct 2021 07:30:32 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B173A175E for <tls@ietf.org>; Thu, 21 Oct 2021 07:30:31 -0700 (PDT)
Date: Thu, 21 Oct 2021 16:30:27 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20211021163027.2dd6c9a5@computer>
In-Reply-To: <CAObGJnObgKwJE6dHUE_bPOHAzYNgaSDguXCz6gZ1Ld9bVKfecg@mail.gmail.com>
References: <CAObGJnObgKwJE6dHUE_bPOHAzYNgaSDguXCz6gZ1Ld9bVKfecg@mail.gmail.com>
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yIxAAGXul_ElfelVIJYxbQsEueA>
Subject: Re: [TLS] DTLS RRC and heartbeat
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 21 Oct 2021 14:30:44 -0000

On Thu, 21 Oct 2021 10:35:54 +0100
Thomas Fossati <tho.ietf@gmail.com> wrote:

> One problem is - as Hannes put it - that heartbeat has a "somewhat
> tricky history", making its marketing a slightly intricate operation,
> and the code reuse story a bit more complicated than desired (see for
> example [3]).

I think there were a few things that went spectacularly wrong with the
original heartbeat extension. Some of them are implementation issues
(like merging code without proper review and testing), but others are in
the spec itself.

I think this boils down to two things that added unnecessary
complexity, which is always bad in security:
1. The use cases were all UDP, but the extension was defined for both
   UDP and TCP for no good reason.
2. The extension contained a completely unnecessary length-encoded
   message that was sent forth and back. That's a very risky
   construction in terms of memory safety.

I feel this may be enough justification to define a hearbeat-simplified
spec that doesn't have these problems.
If you decide to go with the old heartbeat extension then I'd still
wish you at least adress 1. I think many people have just compiled
openssl without heartbeat, which is a good thing as long as it's not
used anyway. If it gets used in DTLS then at least make sure that
doesn't mean it also has to be enabled in TCP-based normal TLS at the
same time.

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