Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 November 2020 00:43 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861403A1796 for <cfrg@ietfa.amsl.com>; Mon, 16 Nov 2020 16:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 JKM1EjFPMEsy for <cfrg@ietfa.amsl.com>; Mon, 16 Nov 2020 16:43:04 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D29B3A1793 for <cfrg@irtf.org>; Mon, 16 Nov 2020 16:43:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EEB0BE74; Tue, 17 Nov 2020 00:43:01 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDBDtWaWeQ-9; Tue, 17 Nov 2020 00:43:00 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0DD0BE64; Tue, 17 Nov 2020 00:42:59 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1605573780; bh=xBRLXLTKmwTaCoegq6JS2QHsUkVwttdlTOUixdUUARY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xYC6flgZx8gVlCw17UiKbwymYR6D9t6n3XtLyjDaynOlameIq/D1ZjkRsJlBjCcPS /iUkdUxmnEHiiqU8ILl5FDg0QELb/a53Z4EwDgRFz7p1vJvB40z6ZZ7WszNsOiVLhp s2zGvWityVn3Vp7XnirANAiHmZCSP2zoCkkKklZY=
To: Eric Rescorla <ekr@rtfm.com>
Cc: CFRG <cfrg@irtf.org>
References: <A3C540A2-6B18-42E0-8F0F-B4723BC5F0DA@ericsson.com> <26fe988b-c2a8-2202-19ed-03b1b2d62d3e@cs.tcd.ie> <CABcZeBNX7J3pwvvTDhq4ugpu=auoZ8Saoq2C3Kx8w-mahLmEvQ@mail.gmail.com> <8390ffe5-2089-6efa-5b83-d96491b3889c@cs.tcd.ie> <CABcZeBMm3-2sHciVJPmcL4M49ezhP1O_52x4QExpH+kB6z5Cew@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <0e959c4c-87c6-0c4a-d605-a7ebac4f30ce@cs.tcd.ie>
Date: Tue, 17 Nov 2020 00:42:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <CABcZeBMm3-2sHciVJPmcL4M49ezhP1O_52x4QExpH+kB6z5Cew@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="BipXciVlmUqiXQ61yrtWyXu0QgimFfJKq"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1eAAoVfGa6u3jcyG26SPs39VZcI>
Subject: Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 00:43:07 -0000

Hiya,

On 17/11/2020 00:38, Eric Rescorla wrote:
> What stops the TLS or QUIC stack from rekeying internally
> when it hits the limit without even notifying the developer.

The heat death of the (developer's local) universe? :-)

I can some envisage developers reading text like this
draft and concluding that they'll never hit the relevant
limit (or more likely assuming that, as it means writing
and testing less code) and never writing any code to
trigger a re-key.

Given the more likely risk is leakage rather than
exhausting the crypto-lifetime of a key (in at least
many cases), text addressing that may be useful.

Cheers,
S.