[TLS] Abbreviated Handshake != Renegotiated Handshake
Ravi Ganesan <ravi@findravi.com> Sat, 19 December 2009 17:13 UTC
Return-Path: <ravi@findravi.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBBD3A698F for <tls@core3.amsl.com>; Sat, 19 Dec 2009 09:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.259
X-Spam-Level:
X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Vr+IzkMm2rv for <tls@core3.amsl.com>; Sat, 19 Dec 2009 09:13:37 -0800 (PST)
Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id A57D03A6B24 for <tls@ietf.org>; Sat, 19 Dec 2009 09:13:32 -0800 (PST)
Received: by pzk6 with SMTP id 6so2943439pzk.29 for <tls@ietf.org>; Sat, 19 Dec 2009 09:13:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.237.37 with SMTP id k37mr3527839wah.31.1261242794988; Sat, 19 Dec 2009 09:13:14 -0800 (PST)
Date: Sat, 19 Dec 2009 09:13:14 -0800
Message-ID: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0016e64b95b6c55414047b17f870"
Subject: [TLS] Abbreviated Handshake != Renegotiated Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Sat, 19 Dec 2009 17:13:42 -0000
> > > Ravi Ganesan wrote: > > > I know everyone on this thread knows otherwise, but the way the terms get > > used, can easily result in confusion between "full handshake", > "abbreviated > > handshake" and "renegotiated full handshake". The attack only applies of > > course to last category, and NOT to the abbreviated handshake. > > Well, it also applies to a renegotiated abbreviated handshake (where a > renegotiating handshake resumes an existing session). The spec should > probably point out that this case is possible, and that exactly the same > attacks and defences apply. > > David-Sarah Hopwood ? http://davidsarah.livejournal.com > > This may be my ignorance, but I assumed the purpose of renegotiation was a fresh exchange of authentication and/or keying material. The renego for instance can (infamously) require client-auth while the original did not. Or switch ciphersuites. The abbreviated handshake cannot achieve any of this. It does not involve certs or ciphersuites. I thought historically its purpose versus: the full handshake exchanges the master-secret in the context of a particular TCP-socket. If the Client wants to use that same master secret in the context of a new ( or a million parallel) TCP sockets, then use the abbreviated handshake (avoiding the PKI heavy lifting). The same thing applies if the binding underneath is not TCP. The abbreviated handshake really has only one purpose in life -- it binds the new SSL session (say the new TCP socket) to the old one, by each party proving knowledge of the original master secret. (exactly what the renegotiated handshake chose not to do). Examples would be a messengering client that negotiates a full handshake with a switch and then each time a new socket is opened for a new message uses the abbreviated handshake. Or a page with many many SSL protected objects that are independently retrieved. So in this context a "renegotiated abbreviated handshake" seems strange. But regardless even if there is something in existence called a "renegotiated abbreviated handshake", I think the distinction between 'abbreviated handshakes without renegoitation' which are very very widely used should not be confused with 'renegotiated handshakes of any kind'. It would be very helpful if the draft made this point.
- [TLS] Abbreviated Handshake != Renegotiated Hands… Ravi Ganesan
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Marsh Ray
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Ravi Ganesan
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Michael D'Errico
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Eric Rescorla
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Ravi Ganesan
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Michael D'Errico
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Martin Rex
- Re: [TLS] Abbreviated Handshake != Renegotiated H… David-Sarah Hopwood
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Ravi Ganesan
- Re: [TLS] Abbreviated Handshake != Renegotiated H… Martin Rex