Re: [TLS] Call for Consensus on removal of renegotiation

Eric Rescorla <ekr@rtfm.com> Thu, 26 June 2014 17:46 UTC

Return-Path: <ekr@rtfm.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 8FDAE1B2C75 for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 10:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 hgTcTZ4sSm7U for <tls@ietfa.amsl.com>; Thu, 26 Jun 2014 10:46:08 -0700 (PDT)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAD11B2DF4 for <tls@ietf.org>; Thu, 26 Jun 2014 10:39:06 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u57so3912415wes.5 for <tls@ietf.org>; Thu, 26 Jun 2014 10:39:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Wigyed5pgR+ADUvDH6J1bdCdsGH1/WJI6jSmMKwddSU=; b=AlmvwlnzO4pGuNLBe/rxioPvtwJyfhpCgpIrOPscI0/UJlHtXYTZ83A3RnoYNzxKmL hlD34vDZMzblO6eM3/xIIvPOHpm0apcHLZxvuDEEUBRhbMmbC97FFpmUKh9VD71Ma58d IURuqx2z34z+H31vEhsI+40iItjtESr/uKFX13Yf+TizeERdmTu8l3QxyswIPPXD5fOT zeS5l4F2/UU7u/PnkqVGnCqgmUtPcI+0GEXvAGRXZ3qrOR1Exhn5z3ZgCMdacFzxegOE Kav9sx7m7hfquOHmLWorU+M3hsqrhSXpVAIgpzwZua/AbqbA7TUqsPfaH15lHZntFIfN doQQ==
X-Gm-Message-State: ALoCoQnKrdEqQ7mOVuuvt4LGyIqhoWOglXI3r+DT2IxjsuuDD+yy9FtgIAHQgwxqSY8MS6YJo5mx
X-Received: by 10.194.192.201 with SMTP id hi9mr15912395wjc.28.1403804341009; Thu, 26 Jun 2014 10:39:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 10:38:20 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:e88c:a4b4:d3a:6b6a]
In-Reply-To: <1403803975.24165.5.camel@dhcp-2-127.brq.redhat.com>
References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <CAAF6GDdkkuB=Eko55vqaPS9Krc0XmiQk0vo2c_q5n6kydpkYuQ@mail.gmail.com> <B18B3440-8CBF-4B04-B792-F81FBF0CE8AC@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> <E4994CAA-947E-43A5-962B-B12CFEF704BB@gmail.com> <1403803975.24165.5.camel@dhcp-2-127.brq.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 26 Jun 2014 10:38:20 -0700
Message-ID: <CABcZeBNMvDf3=tTKXpMsVi=v2iLg-W39w0jzY7cmj-pc1_huWg@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: multipart/alternative; boundary="047d7b8739a814970704fcc0ab8f"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/skIlbtTtPo3ZCKMknKP-89QxPkM
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation
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: Thu, 26 Jun 2014 17:46:11 -0000

On Thu, Jun 26, 2014 at 10:32 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> On Thu, 2014-06-26 at 18:48 +0300, Yoav Nir wrote:
>
> > > Current FIPS states that you can't encrypt more than 64GiB with a
> single key
> > > using AES-GCM. It's not a lot, and it is definetely in the realm of
> possibility
> > > even for HTTPS (games, disk images), let alone actually long lived
> connections…
> > That number seemed suspiciously low, so I went and read SP-800-38D.
> > It recommends two different limits depending on the length of the IV.
> > For IVs that are constructed deterministically, but whose length is
> *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4
> billion TLS records, which could be up to 16 Terabytes.
> > But that doesn’t matter anyway, because in TLS the recommendation is to
> create the nonce deterministically and the length *is* 96 bits, so the
> limit is 2^64 invocations.
> > Even with 1-byte records, that’s more terabytes than we know what to do
> with.
> > So I stand by what I said earlier. Just because of volume, there is no
> reason to rekey an AES session.
>
> That's true for TLS. DTLS has its record counter is limited to 2^48
> bits, and that could require a rekey as it is often used for long-lived
> VPN sessions. Of course this call is about TLS though
>

I would expect any decision made here to apply to DTLS as well.

-Ekr