Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <martin.thomson@gmail.com> Tue, 27 May 2014 22:31 UTC

Return-Path: <martin.thomson@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 8FFCC1A0794 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 15:31:11 -0700 (PDT)
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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 1_QEcxQXLqKm for <tls@ietfa.amsl.com>; Tue, 27 May 2014 15:31:09 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A501A02A2 for <tls@ietf.org>; Tue, 27 May 2014 15:31:09 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id y10so10032037wgg.25 for <tls@ietf.org>; Tue, 27 May 2014 15:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AowrC8X/RpHtLcEgpf5QrpjUOn1H5DrgFYbSPVtc0j0=; b=bTehCaaepuZrpLedGVin8HWXnn6Nshp7XR/ORf7iTq4YCRS6/DtmFzGAsB8byeXCoD 8ndg4acaiz7Wfg/GPX+VgYltazUP90AW+EzUw+WpB/S/ncVmXY0I4GVhPtPiiBnYu6J5 x5FkFg/dqp+/ca+akoPT12QwenTLZAFewmQdxx3eHJvGKy32u6UXckZO59KbZ8Ti9q2Q rWmrSpuXDdt/6noMO9mOT390ZsvMdMbYmrCXedbnSNIvrN/WBYtI5AighERSVS1vSzYH 29unk6zBOFBzaUrbnJ2hDM4bUKO2R9PO0QqWEyiW40CArUiwIxqA7VTzcbhMMzoqWK8d gN4A==
MIME-Version: 1.0
X-Received: by 10.180.97.10 with SMTP id dw10mr42769767wib.38.1401229865210; Tue, 27 May 2014 15:31:05 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Tue, 27 May 2014 15:31:05 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
Date: Tue, 27 May 2014 15:31:05 -0700
Message-ID: <CABkgnnV6aP7NQvxPt+kdggwWnut=7xNp4K+Y5G2yWA9_yNob_g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z6NsmHyPOtmtOA_QoNOvyKOSElk
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: Tue, 27 May 2014 22:31:11 -0000

On 27 May 2014 15:18, Salz, Rich <rsalz@akamai.com> wrote:
> I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state is thrown away and it's just as if the client first connected.  It avoids TCP reconnect, perhaps requires more work (but the EDH key should be cached), but it seems much clearner.

If I understand you correctly, and I'm not sure, are you proposing
that we close the TLS connection, but not the TCP connection.  Is the
assumption that we have a 0RTT handshake that is piggybacked
immediately after a close alert so that application data can continue
to flow?

It's certainly clean, in the sense that you get a completely new
security context without some of the overhead.

But it seems a little heavyweight to me.  I'm also concerned about the
performance implications.  A 1RTT handshake would end up with dead air
on the client side if they initiate this, and even with 0RTT, the
server is always penalized if they initiate.  That is, unless we allow
for role inversion, which would make my head hurt.