Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 23:24 UTC

Return-Path: <mrex@sap.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 5E2DB3A6927 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.562
X-Spam-Level:
X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OEM_BRC=1]
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 Lwxug+EwIpOz for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:24:36 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 528053A6924 for <tls@ietf.org>; Thu, 5 Nov 2009 15:24:36 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5NOuR8015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 00:24:56 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911052324.nA5NOtdH021096@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Fri, 6 Nov 2009 00:24:55 +0100 (MET)
In-Reply-To: <4AF351A9.30409@extendedsubset.com> from "Marsh Ray" at Nov 5, 9 04:28:57 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 05 Nov 2009 23:24:37 -0000

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. 


The (OEM) SSL/TLS library that we ship does not support renegotiation
in the server implementation, so I never thought about the implications
of using renegotiation on the server side.

And when we started shipping SSL, my knowledge about the SSL/TLS protocols
was quite limited.  My expertise was mostly around GSS-API at that time.


-Martin