Re: [TLS] To extend or not to extend

[Nicolas Williams <[e-mail]>]

On Sun, Nov 15, 2009 at 03:13:01AM -0800, Joseph Salowey (jsalowey) wrote:
> E. The RI proposal has an issue if the client is patched and the server
> does not implement the SSL 3.0 and the TLS 1.x specs correctly and the
> client as a lenient policy which allows connection to insecure servers.
> In this case the client would have to implement some fallback logic
> (reconnect without extensions) to deal with broken servers.  This logic
> is well-known, but it leaves a roll-back attack open.  This can be
> plugged by using the proposed ciphersuite signal only in the case where
> extensions cause a handshake or connection failure.  The fallback
> cipher-suite signaling for RI to prevent rollback extends TLS in an
> unexpected way, but this is limited only to the case where we have to
> deal with broken implementations.  

No, I don't think so.  The RI proposal is fine in all respects, except
that if there are old servers that are broken w.r.t. extensions and
which could get patched to implement a simple fix, then RI is possibly
too complex.  Or at least that's what I think Martin is arguing.  I'm
not sure that's the case either.

I think the RI is fine, but if it's not (see above) then we need _data_,
meaning: names of implementations and implementors that are committed to
fixing such old SW and who prefer a non-extension-based solution.

> The ciphersuite-changes-handshake proposal has similar properties except

Which proposal is that??  I proposed a fix that changes only the
Finished message verify_data computations.

> I think it comes down to whether we want to extend TLS in a standard way
> for compliant implementations with a non-standard fallback behavior for
> handling non-compliant implementations or extend TLS in a non-standard
> way for all implementations.   The standard vs. non-standard is somewhat
> nonsensical because we can make something standard with IETF consensus,
> however this will have implications on implementations and future
> extensions moving forward.  

I agree.  I dislike the argument that Hello extensions, being the
blessed extensibility facility of TLS, is what must be used, but that
alone is not enough to ditch EKR's proposal!

> IMO, given that the two approaches are functionally equivalent I would
> prefer to extend things in the standard way. 

EKR's proposal is being interop tested as we speak.  That gives it a
head start.  IMO I think we'll end up with that.  IMO folks who really
want an alternative will have to come up with data (see above).

Nico
--