Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <martin.thomson@gmail.com> Wed, 28 May 2014 17:42 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 9D7F51A0A26 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 10:42:59 -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 4kOOIXv40v6g for <tls@ietfa.amsl.com>; Wed, 28 May 2014 10:42:55 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455C31A0494 for <tls@ietf.org>; Wed, 28 May 2014 10:42:55 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so11800618wes.28 for <tls@ietf.org>; Wed, 28 May 2014 10:42:50 -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=6a51K3B4V/BAMeYr7YVqpL/Jh7EW7K3x6937JwOpRjk=; b=BPY+BX0Cpszle/zWqZWycTnQz/B9KZQl+9w/Ji6abqzS2BF/9orPM53rb0TutrD3gd BnqpmGWBYJkcA25M1QbksJS+P6IAfMpKuE/7MfMLPrSAzDMZqQiI4lJ2He0nY79lHQ8L 8gYVFJcBziub4pX0YG94aNEVaj43YM+OJAXp5QHbL31FpidlfcpyNAQGDE2SFBBYBvxK e9A3SWEbwu8nzTkJbGwC8vrB+n01Tns1ORwSemekCP6PvHBZhWCp/k79kQo0MmllQyyl zc9ZbhZchIlDKYx54lzv8ehamYxeJN5JlQ2idBuQY9mssq231Y/y0KDcr6OF+rWKNGji Ijpg==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr51379273wiv.44.1401298969917; Wed, 28 May 2014 10:42:49 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 10:42:49 -0700 (PDT)
In-Reply-To: <CAFewVt6Y_+HKmGvCNY0WsUOgQiwhUZsDgfG=v-MfL9+PHqqiVg@mail.gmail.com>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <CAFewVt5GCmH8wSdUYLy_Q9RNEtAggzG3_k-9E8ME-nP9jZNX3Q@mail.gmail.com> <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com> <CAFewVt6Y_+HKmGvCNY0WsUOgQiwhUZsDgfG=v-MfL9+PHqqiVg@mail.gmail.com>
Date: Wed, 28 May 2014 10:42:49 -0700
Message-ID: <CABkgnnWhUvjbHm+fRa5o9a2JX3AgSe8Woj=UzdHNucwsKu8vAw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JXEvle1SiXLOywdfk9xD_uXUtAg
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 17:42:59 -0000

On 28 May 2014 10:35, Brian Smith <brian@briansmith.org> wrote:
>> 2. Connections that carry so much traffic and last so very long that you
>> really need to rekey. This was discussed at the meeting, partially on Jabber
>> ([1]). It’s not that common for the web, but I’m assured that XMPP
>> connections sometimes last basically forever, so they need rekeying. My
>> proposal there (at 19:40) was for this use case. Martin is right that it
>> adds “dead air”, but all these use cases are not that delay sensitive, and I
>> think it’s worth it to get the simplified state machine.
>
> As you say, these applications are not delay sensitive.

The specific example we've been given was XMPP.  That is somewhat
delay sensitive.  These high volume channels can't really afford to
waste round trips.  Now, a make-before-break arrangement might be
enough.  I can ask an expert.