[TLS] To extend or not to extend

["Joseph Salowey (jsalowey)" <[e-mail]>]

We need to close on this issue.  To summarize the RI proposal (the draft
submitted last week) has the following properties in various situations


A. The RI proposal works fine if both client and server are patched.  

B. The RI proposal works fine if the client is not patched and the
server is (the server ends up disabling re-negotiation).  

C. The RI proposal works fine if the client is patched and the server is
not, if the server is implemented correctly. 

D. The RI proposal works fine if the client is patched and the server
does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if
they see an extension) and the client desires to implement an secure
policy and disallows connections to non patched servers

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.  

Situation E is one that we expect to get less common because we want all
implementations to get patched and clients may start requiring the fix
because this is the only way they can protect themselves.   

The ciphersuite-changes-handshake proposal has similar properties except
we expect that there are few broken servers that will barf on an unknown
ciphersuite (Situation E).  This proposal extends TLS in a non-standard
place by having the presence of a specific ciphersuite act as a side
channel to change the behavior of the TLS handshake for all current
versions of TLS.   I don't think this is something that we would want to
promote in the future, the code to handle this would be "one-off" code.

>From a functional point of view I don't see any difference between A) RI
extension with option ciphersuite signal in the case of fallback for
broken servers and B) ciphersuite-changes-handshake proposal.  

In TLS we have two standard ways of extending the functionality defined.
One is extensions and one is the version number.  Changing the version
number is not really helpful at this point because it would require all
systems to update to TLS 1.3 and its not clear that any of the
situations above would change.  Extensions are the way to extend the
spec.  Extensions are now part of the base specification and we want
implementations to process extensions correctly even if they only
support the RI fix.  

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.  

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