[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.