Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 06 November 2009 00:15 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 1C26528C10F for <tls@core3.amsl.com>; Thu, 5 Nov 2009 16:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.015
X-Spam-Level:
X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, 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 Jl9MKN0Z6qQu for <tls@core3.amsl.com>; Thu, 5 Nov 2009 16:15:35 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id AFFC73A68B3 for <tls@ietf.org>; Thu, 5 Nov 2009 16:15:28 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA60Fno8025713 for <tls@ietf.org>; Fri, 6 Nov 2009 00:15:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA60Fn4S020036 for <tls@ietf.org>; Thu, 5 Nov 2009 17:15:49 -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 nA5Nun8L009751; Thu, 5 Nov 2009 17:56:49 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5NumgR009750; Thu, 5 Nov 2009 17:56:48 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 17:56:48 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091105235648.GP1105@Sun.COM>
References: <4AF351A9.30409@extendedsubset.com> <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] TLS renegotiation 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: Fri, 06 Nov 2009 00:15:36 -0000

On Fri, Nov 06, 2009 at 12:24:55AM +0100, Martin Rex wrote:
> Marsh Ray wrote:
> > 
> > I would add here that if the IETF had compared the way TLS looks on the
> > wire with how it is presented by SSL APIs in practice, this defect could
> > not have gone unnoticed.
> 
> I would like to put this differently.
> 
> There are several different APIs and API architectures for SSL/TLS
> protocol stacks.  If you really want to verify a spec, there is
> no better way than implementing it.  As an implementor, you get
> to see both, the TLS protocol engine as well as the API that
> you make available to application callers.
> 
> And when an implementer describes to its consumers how to use
> the implementation and how to architect the applications usage
> of TLS, this problem should really have been noticed.
> 
> 
> Finding problems when discussing things at an abstract level
> is MUCH MUCH harder.  You notice that when people define
> protocols with ASN.1 elements.  It's almost exclusively
> the implementors who find the problems. 

Implementors, on the other hand, may not have the experience necessary
to determine the consequences of a flaw like this, they may (and
probably did) just shrug.  More likely though, you can't really predict
who's going to find any given vulnerability.

Providing more information, more views, always helps.  In this case it
would have.  But then, too, we should keep in mind that there are many
possible TLS API designs -- Marsh is saying, I think, that the SSPI-/
GSS-API-like ones that would have made this flaw obvious, and I agree.