Re: [TLS] TLS Digest, Vol 65, Issue 88

Ravi Ganesan <ravi@findravi.com> Mon, 21 December 2009 18:27 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 8B6663A6889 for <tls@core3.amsl.com>; Mon, 21 Dec 2009 10:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.131
X-Spam-Level:
X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 V7uKCfTzf9dx for <tls@core3.amsl.com>; Mon, 21 Dec 2009 10:27:57 -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 574203A6405 for <tls@ietf.org>; Mon, 21 Dec 2009 10:27:57 -0800 (PST)
Received: by pzk6 with SMTP id 6so3927193pzk.29 for <tls@ietf.org>; Mon, 21 Dec 2009 10:27:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.163.16 with SMTP id l16mr1519811wae.39.1261420058293; Mon, 21 Dec 2009 10:27:38 -0800 (PST)
In-Reply-To: <mailman.6034.1261412925.32729.tls@ietf.org>
References: <mailman.6034.1261412925.32729.tls@ietf.org>
Date: Mon, 21 Dec 2009 10:27:38 -0800
Message-ID: <3561bdcc0912211027l642d7085kf825965d3b0d6ec9@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="00504502f58f7cb807047b413ec8"
Subject: Re: [TLS] TLS Digest, Vol 65, Issue 88
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: Mon, 21 Dec 2009 18:27:58 -0000

>
>
>
> Ravi, your terminology is slightly confusing.  Renegotiation refers
> to a TLS handshake that is performed under protection of an existing
> TLS session, so the two things you could distinguish are:
>

Martin, Point well taken. Thx, Ravi

p.s. I prefer not to think of the handshake happening "under protection" of
previous session. Another example of this is in current draft which says:
"The handshake is in the clear to the attacker but encrypted over the
attacker's TLS connection to the server." The handshake itself is always of
course is in the clear, certain values in it are encrypted with certain
keys. And in some cases this results in binding to previous sessions. This
sounds nitpicky, but I only say this because perfectly smart security people
with some knowledge of SSL can read sentences like above to assume the
entire handshake (including client_random and server_random) is encrypted.