Re: [TLS] TLS renegotiation issue

[Nicolas Williams <Nicolas.Williams at sun.com>]

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
reasons:

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

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
proposal.

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
conformance.

Nico
--