On 2009-12-02 15:26 PST, Marsh Ray wrote:
> Nelson B Bolyard wrote:
>>  ... for servers that have never been conformant with the standards that
>> require them to ignore unknown extensions, yes.  Another way to say this is:
>> non-conformant servers are a known interop problem for conformant clients.
>> That fact is manifestly obvious now, as we see attempts to retroactively
>> codify the behavior of those non-conformant servers as we try to fix this
>> problem.
> 
> Hold on now, is there any reasonable interpretation of
> draft-ietf-tls-renegotiation which "codifies the behavior of those
> non-conformant servers"?

Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF*
(rather than in addition to) the RI extension is such an attempt.
Such proposals now exist.

> TLS implementations have every right under current specs to send and
> receive hello extensions. Higher-level protocols have the right even to
> require them.

And some server vendors believe they have every right to reject client
hellos that include any hello extensions.  They now vociferously propose
that we design the solution to the renegotiation vulnerability so that,
even after they have patched their servers for this vulnerability, their
servers can CONTINUE to reject client hellos with hello extensions.
That's the issue here.

> This is an urgent bug fix, not an upgrade, and as such most of us share
> the goal of causing absolutely minimal disruption to existing systems.
> 
> Sometimes even perfectly-conformant clients are asked to connect to TCP
> port numbers on which a few *gasp* imperfect servers are listening.
> Since this sometimes results in a hung connection, the condition can
> only be detected after a (relatively) long timeout.

Those servers MUST be patched now.  It's a simple thing to patch them to
be tolerant of (that is, to IGNORE) client hellos.  But they steadfastly
refuse.  Instead they demand that we retroactively modify the definition
of TLS to explicitly recognize and legitimize this extension-intolerant
behavior.

> The recognition of this reality, done purely in consideration of the end
> users of this technology, does not in any way "codify the behavior of
> those servers".

If it effectively requires that new client products MUST implement fallback
to be interoperable with conformant servers, then it most certainly does
codify that behavior.

>>> While I've seen evidence of bugs in TLS extension handling, and backwards 
>>> compatibility fallback code that's been present in browsers since 1999, 
>>> I've seen no evidence that extensions are an interoperability problem for 
>>> correct standards-compliant TLS implementations or that such fallback code 
>>> is necessary in operation today.
>> +1.
> 
> I agree in principle.
> 
> In this case though, it would be asking application code owners to rip
> out their fallback logic. Many of them would be willing to do it of
> course, but it would still fall short of our goal to engineer a fix
> which is deliverable as a patch only to the TLS library.

I think you've got it backwards with respect to who is asking whom about
the ripping out.  The browsers WANT to rip it out.  They want to eliminate
the latency associated with the fallback.  The attempt in some present
proposals to permanently legitimize those old servers that never ignored
unrecognized extensions tells the browsers that they can never rip it out.

It is doubly ironic that the proponents of this approach are using the
existent of fall-back and the justification for their proposal.  The
argument seems to be "We once forced browsers to fall back, and the browsers
have never removed that feature.  Now we claim the on-going
existence of that fall back amounts to on-going demand for the behavior
of our old servers.  So, the standards MUST now explicitly provide for
our servers."

Regards,
/Nelson