Re: [TLS] TLS renegotiation issue

Nicolas Williams <> Fri, 06 November 2009 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 150F93A67F3 for <>; Thu, 5 Nov 2009 16:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.015
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bnlJ70IsLWTY for <>; Thu, 5 Nov 2009 16:24:07 -0800 (PST)
Received: from (sca-ea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 3547F3A67E2 for <>; Thu, 5 Nov 2009 16:24:07 -0800 (PST)
Received: from ([]) by (8.13.7+Sun/8.12.9) with ESMTP id nA60OU82001143 for <>; Fri, 6 Nov 2009 00:24:30 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA60OTPo023985 for <>; Thu, 5 Nov 2009 17:24:29 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA60CxkU009766; Thu, 5 Nov 2009 18:12:59 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA60Cxxe009765; Thu, 5 Nov 2009 18:12:59 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Thu, 5 Nov 2009 18:12:59 -0600
From: Nicolas Williams <>
To: Martin Rex <>
Message-ID: <20091106001259.GR1105@Sun.COM>
References: <20091105230343.GO1105@Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
Subject: Re: [TLS] TLS renegotiation issue
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Nov 2009 00:24:08 -0000

On Fri, Nov 06, 2009 at 12:51:59AM +0100, Martin Rex wrote:
> I read your message to mean that applications based on architectures
> like SSPI and GGF will need to modify their code INDEPENDENTLY to how
> we solve the problem to avoid the security problem as well as to adopt
> the solution.

Implementations clearly have to change.  Implementation with a specific
API design that I identified will require application changes to go with
the TLS implementation changes.

> Why do you insist that we make the change in a fashion that
> caters a particular API?

[Overlooking you use of the ver "to insist" for a moment...]  For two

1) If it's not onerous for any other implementors, then making a change
   that makes the fix simpler for some implementors is worth

2) RFC5056 exists and defines channel binding.  Channel binding _is_
   what the proposed fix here actuall does, but in a way that does not
   conform to RFC5056, and in a way that does not conform to APIs that
   have support for channel vbinding work (APIs that can be interfaces
   to TLS).

Not conforming to RFC5056 is hardly fatal.  And if some implementors
have to do ugly things to their APIs and applications using them, well
too bleeping bad.  Right?

But I have a right to ask for the WG to consider making this fix conform
to RFC5056 and not force some implementors to do ugly things to their
APIs.  Not a right to demand, mind you -- the WG consensus can reject my

Rather than cast this as me "insisting" on something or other, how about
debating the actual proposal?  Say what you like or dislike about it.
See where the chips fall.

> I would not mind if those TLS implementers with the GGF and SSPI
> use the terminology and function parameters they formerly called
> "channel bindings" (AFAIK SSPI doesn't have channel bindings)
> to pass along the finished messages described in Erics document.

Neither would I.  Except that they _can't_ with Eric's proposal, not
without violating abstractions and interpreting the contents of the
channel bindings input, which is why I object.

> I am certainly opposed to adopting one particular API's
> terminology and confuse other API architectures where there
> already is an established term for the piece of information
> that we want to carry over between an existing TLS session
> and a new TLS session.

Whatever.  No one asked that you, or Eric, or the WG or anyone else do
that.  There's no need to use SSPI or GSS-API terminology in the
resulting spec.  There is a desire, on _my_ part, for RFC5056