Re: [TLS] Resuming a session as part of a renegotiation.

Alfredo Pironti <> Thu, 19 September 2013 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E133021F943C for <>; Thu, 19 Sep 2013 12:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.479
X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qv4PO5ECJ85p for <>; Thu, 19 Sep 2013 12:07:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::230]) by (Postfix) with ESMTP id AB70021F9433 for <>; Thu, 19 Sep 2013 12:07:16 -0700 (PDT)
Received: by with SMTP id hu16so3909111qab.0 for <>; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3VJYH6gVwlC28jzVO+pyu9PyIr+JY1TLwSS6s26bhg8=; b=Wy7CRYJ0Wsf3xsnetucr28kZ3drAXYMVp/VnIwPS36e18zXgNdfzz+C74V+r+0hJla FoFGXbeExXHwRRy5NlhVXI5fpqbxhp71Z667Xj29zleJ6z+HnGay2DSy7hQIC/vENK8K WcMvCTk41iTTRGOcFSOd5ZlpEl3ejGOdLhx4M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3VJYH6gVwlC28jzVO+pyu9PyIr+JY1TLwSS6s26bhg8=; b=VlZ7KJ4ApAJ+DVHbo1MCo3wN41cOunWIHq+g91HhQUm9cN/wbNhPdeSYCsSSXx3hWQ GsvFbpbDY5F57bSOcmCgAwKcNBjiss6xpS89UHEDrV6ab7Ou1r4Y7dVZeCNMlmNEnYOl CoNJq80Q8D3BC4PK+BCHcIFc4DGKk+hvMAI8sfGN5jCPmocfAgCVt8CwvYPmavSiGcZE Fsz56qz/tWo7TnI3xixksbX0cG96ipkqdMIcUk5lP33w5MfCyj3a8MImOjOjJMoKfq4f gVB6onoEdWSFHkttb09wgkQSC0Ti8D728Q9p0h+pcbt7LQpmWzByha7VBS6duCsU/1jv LxqQ==
X-Gm-Message-State: ALoCoQlZcC5sI6hVVtx7pOVH10KLlKN3OB1EMnY4a+e9KHQjMpOdbKH74Q4ywQE3I1kKAmYDn8M0
MIME-Version: 1.0
X-Received: by with SMTP id q17mr302019qam.92.1379617635611; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
Received: by with HTTP; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 19 Sep 2013 21:07:15 +0200
X-Google-Sender-Auth: huzr4xZq6DuNUdsrply1VtnhTR4
Message-ID: <>
From: Alfredo Pironti <>
To: Yoav Nir <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Sep 2013 19:07:33 -0000

I'd say that, over an existing connection, you'd mostly run an
abbreviated handshake resuming the current session to refresh keys.
You could also use it to reset sequence numbers, in case they're soon
going to overflow. I know no implementation doing that; all of them
seem to happily let the sequence number overflow, assuming the
connection will be tear down way sooner this happens (which is
probably true in most scenarios).

According to the spec, you could even run an abbreviated handshake
resuming a different connection form the current one. In a scenario
which I discourage (because it's asking for trouble confusing the
application), you could have a pool of established TLS sessions, each
using a different identity, and "swap" between them with abbreviated
re-handshakes over the same connection. Again, I'd take this as a
non-forbidden behavior, rather than a largely useful one.

On Thu, Sep 19, 2013 at 8:50 PM, Yoav Nir <> wrote:
> On Sep 19, 2013, at 9:29 PM, Fabrice Gautier <> wrote:
>>> One possible use case: if you negotiated a block cipher with a
>>> small internal state and are sending large quantities of data,
>>> security might be improved by periodically renegotiating.
>> Thats only benefit a full handshake renegotiation.
>> The way I understand it, renegotiation allows you to have several
>> session in the same connection, and session resumption allows you to
>> have the same session across multiple connections.
> Renegotiation just means doing the handshake again. The end result is new keys. So if you believe that 3DES keys should not be used for more than 0.5GB of data, just doing a renegotiation gives you fresh keys (because they are mixed with the new nonces). If you resume the session, you don't get new client and/or server identities, you don't get re-authentication, and you don't get a new master key, so someone who has managed to get your old master key can figure out both your old and new encryption keys. But if the only reason you're renegotiating is that you need fresh keys, that's good enough.
> So renegotiation+resumption gives you the same session, but new keys. Sort of like "phase II" in IKE.
> Yoav
> _______________________________________________
> TLS mailing list