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.
- [CFRG] Comment on draft-irtf-cfrg-aead-limits-01 John Mattsson
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Martin Thomson
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Stephen Farrell
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Eric Rescorla
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Stephen Farrell
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Eric Rescorla
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Stephen Farrell
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… John Mattsson
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… John Mattsson
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Martin Thomson
- Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits… Stephen Farrell