IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Wed, 25 June 2014 21:39 UTC

Return-Path: <ynir.ietf@gmail.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 9D8CE1A0418 for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 14:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 PB0XLDs79DPI for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 14:39:36 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4311A0054 for <tls@ietf.org>; Wed, 25 Jun 2014 14:39:36 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hi2so62987wib.4 for <tls@ietf.org>; Wed, 25 Jun 2014 14:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ST3aR7i7p2yGFhOYzrtJgKV0IIIfhsFHWgrRfsG9FVY=; b=qD9Z+ekgFUFpSsK0O+28mx0b24AuiC2SN1P0lcQinw4Tw0pBTRIJirsKvKwI4kB8pH 3Ctv3U64MZNtGZzWy5EpVBwtjJQCqC5aCcBWsOMnh6IXj5aFsAe48Jdi93f0PZb+XtKE oV3ei8VYDCQtK7zDUOr8kLAcWYRiVg09yj1s5gRmb0oe0epDisGz+FWm2Mj+mHXf974r x31Ey0MG5szPJjTZMMf46/nXYyacFYOMuKysI3kgILv36YWZjM4yUuFwFAzzLaVwWLFP ciMUXFUMnoaUXw2mlfjLj1XjsY207kkdazJ+CYTTUtYkoekDFWCXbi+8n/wdeXJ3AOab RDDw==
X-Received: by 10.180.206.73 with SMTP id lm9mr44819697wic.54.1403732374985; Wed, 25 Jun 2014 14:39:34 -0700 (PDT)
Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id h3sm9929106wjz.48.2014.06.25.14.39.34 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 14:39:34 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAAF6GDdsHo1178Hfs8RzERLPDni9SMHB6+nPg0aWBSkxFv_53w@mail.gmail.com>
Date: Thu, 26 Jun 2014 00:39:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A19581EC-A67A-4CEC-83D1-542F09429A93@gmail.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> <CAAF6GDdsHo1178Hfs8RzERLPDni9SMHB6+nPg0aWBSkxFv_53w@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sOx5CsR4NiC6F8hxqZeyy7yyu1k
Cc: "<tls@ietf.org>" <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: Wed, 25 Jun 2014 21:39:37 -0000

On Jun 26, 2014, at 12:17 AM, Colm MacCárthaigh <colm@allcosts.net> wrote:

> On Wed, Jun 25, 2014 at 1:39 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> Before: The client opens a connection, calls the TLS library, and then transmits arbitrarily-much data for an arbitrarily-long time. If so much data has been transmitted that rekeying is warranted, The TLS library will do it transparently to the application.
>> 
>> After: The client opens a connection, calls the TLS library, and then transmits information. After a while, either a data count passes some limit, or a timer expires, and the application is informed by the TLS library that this connection can no longer be used. So the client opens a new connection and calls the TLS library again. Simple?
> 
> This seems like a strawman argument. Why can't a library make
> connections and hide that detail of the application? Of course a
> library can, as database connection pool libraries do, for example.

I disagree. Suppose we did a telnet-over-tls protocol (yes, of course somebody’s already done it). 

When I’m logged in through telnet (or SSH, or telnet-over-tls), I enter some credentials, and I get an environment. It’s fine for the library to take over sockets and such, but the server has to (a) be convinced that the new connection is associated with the same user, and (b) associate the old environment with the new connection. 

I don’t see how you can do that without modifying telnet.  Can you?

Yoav

v2.23.0 | Report a Bug | By Email