IETF Logo Mail Archive

Re: [TLS] TLS or HTTP issue?

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 09 November 2009 02:56 UTC

Return-Path: <Nicolas.Williams@sun.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 75DA13A6A4E for <tls@core3.amsl.com>; Sun, 8 Nov 2009 18:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.016
X-Spam-Level:
X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 0pJDycbzHJQb for <tls@core3.amsl.com>; Sun, 8 Nov 2009 18:56:13 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 484103A68E5 for <tls@ietf.org>; Sun, 8 Nov 2009 18:56:13 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA92ub9A015556 for <tls@ietf.org>; Mon, 9 Nov 2009 02:56:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA92uboF026823 for <tls@ietf.org>; Sun, 8 Nov 2009 19:56:37 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA92j6C0011457; Sun, 8 Nov 2009 20:45:06 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA92j5sM011456; Sun, 8 Nov 2009 20:45:05 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Sun, 08 Nov 2009 20:45:05 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091109024504.GT1105@Sun.COM>
References: <4AF444EE.9070401@manchester.ac.uk> <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS or HTTP issue?
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, 09 Nov 2009 02:56:14 -0000

On Fri, Nov 06, 2009 at 06:13:44PM +0100, Martin Rex wrote:
> From the original design, and in the two quoted paragraphs above,
> it appears that SSL and its successor TLS was intended to be
> _very_ transparent, and the spec contains guidance for
> security-relevant signaling to the application only for
> the initial TLS handshake on a connection (full initial handshake,
> and session resume), but _NOT_ for the session renegotiation.
> 
> Therefore, I think, we do have a real shortcoming of the
> SSL/TLS protocol, and we really should scramble to fix it.
> 
> That includes improving on the guidance for the signaling
> and semantics of a TLS session renegotiate of the TLS
> protocol stack to the application -- in a fashion so that
> it can be folded back into rfc5246bis.

"Signaling" --- sounds like an... API!

Nico
--

v2.23.0 | Report a Bug | By Email