[TLS] Fallback SCSV summary

[Joseph Salowey <[e-mail]>]

Below is my summary of the fallback SCSV issue with some suggestions.
Since I'm weighing in on the text as an individual I'm asking Sean to
finish up the consensus process on this draft.

I've gone through he SCSV comments and I think the following issues need to
be resolved:

1.  The draft does not really state that the fallback SCSV is really a hack
and that standard version negotiation should really be encouraged.  Here is
some text that could go into the introduction:

"The fallback SCSV defined in this document is not suitable substitute for
proper TLS version negotiation. TLS implementations need to properly handle
TLS version negotiation and extensibility mechanisms to avoid the security
issues and connection delays associated with fallback mechanisms."

2.  The current draft will cause TLS connections to fail if a downgrade
happens for any reason.  This will result in additional retries even if the
server is willing to continue at the lower version.  An alternative using
extensions has been described to allow the server to communicate the status
of the downgrade back to the client and let the client decide whether to
continue.

>From reading the list I don't think we have consensus to abandon the the
SCSV approach.  The SCSV mechanism is simpler and it does not rely on
extensions which have been a reason for server failures in the past.
However, I think the draft can better describe the conditions of when the
client SHOULD include the SCSV and what the client SHOULD do if it receives
an inappropriate_fallback alert.  Here is some proposed text for section 4
and security considerations:

Section 4

"If the client receives an inappropriate_fallback alert then the server
intends to support a higher version and the client should retry with the
highest version it supports.   Implementors should review the security
considerations section before deciding to make a connection with a lower
version without including the TLS_FALLBACK_SCSV.

Security Considerations

"Section 4 does not require client implementations to send
TLS_FALLBACK_SCSV in any particular case, it merely recommends it; behavior
can be adapted according to the client's security needs.  However, it is
important to remember that omitting the TLS_FALLBACK_SCSV leaves the TLS
connection vulnerable to version rollback so it is not recommended to omit
the SCSV unless the negotiated version provides an acceptable level of
protection.

For example, during the initial deployment of a new protocol version
(when some interoperability problems may have to be expected),
   smoothly falling back to the previous protocol version in case of
   problems may be preferrable to potentially not being able to connect
   at all: so TLS_FALLBACK_SCSV could be omitted for this particular
   protocol downgrade step.

   However, it is strongly recommended to send TLS_FALLBACK_SCSV when
   downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
   weaknesses that cannot be addressed by implementation workarounds
   like the remaining weaknesses in later (TLS) protocol versions."

3.  The introduction should indicate that the Fallback SCSV also applies to
DTLS.

4.  The IANA considerations section needs to allocate the number for the
alert:

"IANA is asked to assign the following value in the TLS Alert Registry for
use with TLS and DTLS.

86  inappropriate_fallback Y [RFC TBD]"