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

When considering the impact of applying this fix in certain production
environments I have identified the following issues:

      There is a possibly of legacy systems containing SSL implementations
      that are SSLv3 only and can not negotiate TLS i.e. they have no TLS
      support at all.
      There is a possibly of legacy systems containing SSL implementations
      that are TLS extensions intolerant.
      There is a possibly of SSL implementations that can negotiate TLS,
      but legacy application(s) that can not enable it or always force
      SSLv3 (domino effect).
      Changing the “on the wire” protocol version from SSLv3 to TLS could
      cause handshakes to be blocked by a variety of network
      infrastructure.

I believe an imperative for deploying this fix is ensuring that by applying
the fix no unwanted side effects occur that could break a customer
production environment and that the fix is applicable to the greatest
amount of the installed base as possible.

The following additional note in Section 4 would be useful in addressing
this concern:

Note : Clients that use either of the signaling methods MUST be prepared to
accept a Server response containing the  "renegotiation_info" extension
transmitted in a ServerHello message with the SSLv3 protocol version {
0x03, 0x00 } and MUST continue with protected renegotiations at this
protocol level.

Additionally, I believe that adding extensions in the initial ClientHello
could result in adverse customer events in some very small number of
environments that are extensions intolerant [1].  The following additional
note in Section 5 would be useful in providing guidance in mitigating this
concern:

Note :  In cases where a ClientHello protocol behavior change from not
sending extensions to sending extensions is a risk where legacy Servers may
exist that are extension intolerant then the Client MAY mitigate this risk
by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHOULD
NOT send the "renegotiation_info" extension unless the Client is sending
other extensions.

[1] The obvious answer is to upgrade the TLS Servers that are TLS extension
intolerant, but this reasoning has the following pitfalls:

   1.  These Servers might not be identified until after the Clients have
       been updated and while they are being located and updated the
       production environment could be down.
   2.  These Servers might be out of service as far as SW updates are
       concerned and unable to be updated.  E.g. the original SW vendor no
       longer exists; newer SW will no longer run on said HW; the ability
       of the vendor to build code for said environment no longer exists.
       This all means that these Servers can not be updated and will remain
       TLS extension intolerant until the customer eventually replaces
       these systems.  Additionally, experience has shown that these
       systems are likely to be vital parts of customer infrastructure that
       have been long overlooked.

- Mick Gray
- IBM
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in legacy environments