Re: [TLS] Renegotiation: trying to summarize

"Salz, Rich" <rsalz@akamai.com> Fri, 20 June 2014 02:25 UTC

Return-Path: <rsalz@akamai.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 3511F1A04B7 for <tls@ietfa.amsl.com>; Thu, 19 Jun 2014 19:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 oTe6ekQvXYD2 for <tls@ietfa.amsl.com>; Thu, 19 Jun 2014 19:25:26 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B52111A04A2 for <tls@ietf.org>; Thu, 19 Jun 2014 19:25:26 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F3BB028506; Fri, 20 Jun 2014 02:25:25 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DEFD02812D; Fri, 20 Jun 2014 02:25:25 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DA7B12049; Fri, 20 Jun 2014 02:25:25 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 19 Jun 2014 22:25:25 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Date: Thu, 19 Jun 2014 22:25:23 -0400
Thread-Topic: [TLS] Renegotiation: trying to summarize
Thread-Index: Ac+MEAI6yDRu5Dr6Rba9mUQS0c6wmgAHZQoQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8A8@USMBX1.msg.corp.akamai.com>
References: <CABkgnnU+9mBdqffcbrmcghH9b3cb_Qh2R-XGWSu6MwB-0y99Lg@mail.gmail.com>
In-Reply-To: <CABkgnnU+9mBdqffcbrmcghH9b3cb_Qh2R-XGWSu6MwB-0y99Lg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/am6r2Ro6B1F_eZfwLqBukRjIz6E
Subject: Re: [TLS] Renegotiation: trying to summarize
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: Fri, 20 Jun 2014 02:25:28 -0000

Nice summary.  One quibble:

> In short, I think that #1 and #2 suggest that there is a potential problem if session properties can change; #3 and #4 reject that thesis.

I don't see how #3 "rejects that thesis."  Actually, looking at your note I would disagree with all of your characterization.  To me, #3 says that change is a problem, so explicitly start a new session if you want to change things.
 
> Some have suggested that it be phrased in API terms as a new connection, that the application needs to request a new connection to get the handshake to happen.  In others, this is just a different spin on renegotiation, with a little dead air while everything is changed out.  In the latter case, I don't see how this is any different to retaining renegotiation.  The former seems like an optimization of #1.

I was thinking that since the TCP(whatever) connecdtion was open, both client and server would already "know" who was on the other side, and if the restarted connection ended up with different identities (on either side), it could signal an error to the application.  Or, either side MAY send an alert if the identity is "unexpected" or different. Maybe that's a SHOULD or even a MUST. Also, for I'd expect that the client could now use the 0RT since it has the server's DH key.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz