Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

[Marsh Ray <[e-mail]>]

Nelson B Bolyard wrote:
> On 2009-12-02 15:26 PST, Marsh Ray wrote:
>> 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.

Hmm, I hadn't thought of it that way.

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

Personally, I believe I have the right to write a server app that
rejects any kind of client I want. I wouldn't claim that such a server
follows the spirit of the TLS RFCs though.

Looking through RFCs 3546, 4366 though, I can't find specific wording
which requires servers to ignore extensions on the client hello that
they don't support.

RFC 5246 says "the rules specified in [TLSEXT] require servers to ignore
extensions they do not understand."

But..
>    [TLSEXT]   Eastlake, D., 3rd, "Transport Layer Security (TLS)
>               Extensions:  Extension Definitions", Work in Progress,
>               February 2008.


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

I think the goal of fixing this vulnerability (which will require
patching every client and server in the world) is already ambitious
enough that it doesn't need to take on other causes. It is also
worthwhile enough that it should specifically avoid taking on any other
causes because to do so is to risk the primary goal.

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

Well that's quite silly of them. I can't imagine why anyone would want
to continue shipping a product which doesn't interoperate well when the
fix is so easy. (Well, I can imagine some reasons but they're all bad ones.)

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

I don't think it requires new clients to implement fallback. It just
provides for clients that choose fall back or want to to be tolerant of
extension-intolerant servers.

Just because the fix doesn't actively break something that previously
worked outside the spec doesn't mean that the spec endorses it.

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

There's more to TLS than just browsers.

The bigger problem is that nobody knows has any idea many apps would
have to be changed if we did not provide a solution for SSLv3. Nobody
knows how many connections would fail if the fix required an extension
on the initial hello.

> They want to eliminate the latency associated with the fallback.

At some point, the gain in market share from the reduced latency will be
greater than the loss due to removing 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."

That is a bit ironic.

Sounds to me like there probably is some customer demand for the
fallback logic, or you would have ripped it out of your browser code
already. Maybe that demand dried up years ago and the logic is leftover
only because no one has the guts to remove it. Probably only by actually
disabling it and seeing who complains can we find out how great that
demand is.

This bug fix is not the place for that experiment.

Or perhaps you were hoping that this bug would be an external event
which forced all competing browsers to remove it, that way you wouldn't
have to be the only one to stick your neck out for this
strict-compliance principle?

This bug fix is not the time for that either.

Good news though. I've talked to developers on all the major browser
vendors now, and you all feel the same way about the fallback logic!

Quit waiting for some cataclysmic opportunity and just do it.

- Marsh