Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 21:56 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 4CD443A690F for <tls@core3.amsl.com>; Thu, 5 Nov 2009 13:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.035
X-Spam-Level:
X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 EmAN8-TYKx9D for <tls@core3.amsl.com>; Thu, 5 Nov 2009 13:56:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4C8833A689F for <tls@ietf.org>; Thu, 5 Nov 2009 13:56:25 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5Lukq2012258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 22:56:47 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911052156.nA5LujHw015785@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Thu, 5 Nov 2009 22:56:45 +0100 (MET)
In-Reply-To: <20091105203817.GK1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 02:38:17 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: ekr@rtfm.com, 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 21:56:26 -0000

Nicolas Williams wrote:
> 
> > Nicolas Williams wrote:
> > > 
> > > I understand.  The spec will just have to be updated to say that the
> > > finished messages (or at least the client one) are to be exported to
> > > applications.
> 
> Eric's view seems to be that the TLS spec should say nothing about this.

I fully agree with Eric.

IMHO, this proposal should become integral part of rfc5246bis.

For the channel bindings topic, in particular when it starts
discussing API issues, I personally would prefer when it
remains in a seperate document.


> 
> > The TLS-specs describe only bits-on-the-wire, protocol semantics
> > and TLS session state management.  The TLS specs are entirely
> > silent on API issues.  (The IETF does not do APIs, and GSS-API
> > is an exception.)
> 
> Wrong.  The GSS-API is NOT the only exception.  There's also SCTP, and
> probably a number of otheres (heck, even IDNA has an abstract API).

Well, OK.

While I was actively participating IETF meeting (1995-1998) it was
pointed out several times in IETF plenaries by IESG members that
the IETF does not do APIs and GSS-API was an exception.

I seem to have missed that this has changed.

-Martin