Re: [TLS] Proposed text for removing renegotiation

Brian Smith <brian@briansmith.org> Wed, 28 May 2014 20:47 UTC

Return-Path: <brian@briansmith.org>
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 56B251A0227 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 DYxvWkVlSHjq for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:47:45 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E854F1A020B for <tls@ietf.org>; Wed, 28 May 2014 13:47:44 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id 63so19626951qgz.16 for <tls@ietf.org>; Wed, 28 May 2014 13:47:40 -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:date :message-id:subject:from:to:cc:content-type; bh=GseFhq3iy8iK0NFkqy4urL0Hnoof9pkBfKi9q2LAMI0=; b=Br3tjh5kCXU5zh6U6vg2sQ5Rfuv6tK8ynVRtQCtB50hC2SceHMMPYlnl9BKOEbztyc 88tTzYacrbsoYnGBoIvdl2NfQD6LdkoH5+JREk74Q5gBtSg/oOuX1AEzyTEMKfqnzwVB yi02pJ8ReKVmDunqnG2S9R4NTa0no97mw6z7yRvXZq2+JdBCj1aktjuxQFq2K4iJxBEl kBMjiARC5dp6ABdxiLwsQEcbTUhQ/ZafQO331ddbzOFYIc0NrO+LfkajcGHtb9o4UEpa Wk3Pc8aWx4bYjEDMWoJUvXrqbg4hjxWebBqVS6RKk41xtSzq8rLLfm+EP4effg/VBEqI jUFw==
X-Gm-Message-State: ALoCoQlzg29FAWRud+TIVTOrR1bjaUG6FeGDrvnx4kzAgWVriK2PPu5vAWpDlAa4oSIpIem8cMh8
MIME-Version: 1.0
X-Received: by 10.140.28.3 with SMTP id 3mr3001350qgy.71.1401310060641; Wed, 28 May 2014 13:47:40 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Wed, 28 May 2014 13:47:40 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <CAFewVt5GCmH8wSdUYLy_Q9RNEtAggzG3_k-9E8ME-nP9jZNX3Q@mail.gmail.com> <CABkgnnW0YAhsbMoN0JSdWWpxt9TsOWpvq3c67cw8_eyt4mprbA@mail.gmail.com> <CAFewVt6p95UidCverJ4aHoaHUW7fUEte70fhsxo-Hz6pup=1RQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
Date: Wed, 28 May 2014 13:47:40 -0700
Message-ID: <CAFewVt77h1on93YYTkyOraKp5o94RJxL=w=GJqtL+sX8n4XUCg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary=001a113a34e462932904fa7bec96
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yexQF2vK9YQiHRP-phsg3TtEMQ4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing 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: Wed, 28 May 2014 20:47:46 -0000

On Wed, May 28, 2014 at 1:05 PM, Salz, Rich <rsalz@akamai.com> wrote:

> Ø  The advantage with this is that only the applications that need to
> deal with this problem are impacted by it.
>
> Strongly disagree.  This requires applications to know way to much about
> the TLS layer:  what cipher is being used, how SSL is packing things into
> records, and how often a cipher needs to be “reset” and what that entails.
>

The application would only have to be aware that the connection may at some
point become unusable because the TLS implementation did something like
simulating a RST when some crypto limit is reached. Applications that are
exchanging more than 2^32 records per connection already have to cope
somehow with these long-lived connections being reset below the TLS layer.

And/or such applications could choose to use cipher suites that aren't
limited to 2^32 records. I have just re-read SP-800-38D section 8.3 which
sets the limit on the number of invocations of AES-GCM with a given key.
SP-800-38D doesn't actually limit AES-GCM to 2^32 invocations as long as
the deterministic construction is used and as long as the invocation field
is larger than 32 bits, if I am reading it correctly. The birthday attack
issue on the 64-bit invocation field used in AES-GCM cipher suites could be
mitigated by tightening the requirements for AES-GCM in TLS 1.3 and/or by
defining new AES-GCM cipher suites that are required to have IVs generated
using the deterministic construction with large(r) invocation fields.

And/or, implementations that send/receive large amounts of data on a single
connection could tune their TLS stacks so that they will never (or almost
never) get close to whatever limit the cipher suite has.

And/or the TLS implementation could optionally provide some kind of simple
notification mechanism to tell the application that the connection will
become unusable "soon," so that an application could start a new
connection/session before the old one stops working, to minimize the
performance impact.

Cheers,
Brian

[1] http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf(section
8.3)