Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:


> To me, these two requirements amount to an unnecessary knee-jerk reaction,
> while we are fully aware that most TLS version interop problems are
> non-malicious, i.e. _not_ caused by an active attacker.
>

Well, it's still supposed to be a security protocol, so we *need* to be
able to deal with the situation that the problem is caused by an active
attacker.  Also, even if a security-weakening downgrade is not an
intentional attack, it's still security-weakening.



> I really see harm in increasing the amount of TLS handshake failures
> with new "abort" requirements of the TLS protocol itself.  Any
> new/additional
> handshake failures ought to be left purely and entirely to the calling
> applications and their security trade-offs / policies, which may or
> may not involve the decision of an interactive user.  Our concern in
> TLS WG ought to be reducing handshake failures, and getting rid of
> the reconnect fallback entirely.
>

Yes, downgraded retries are a pain and it would be much better to avoid
them, but that's completely orthogonal
to draft-bmoeller-tls-downgrade-scsv-00.  Whenever you manage to avoid a
retry, nothing in draft-bmoeller-tls-downgrade-scsv-00 applies to that
handshake.

If you have a retry, with draft-bmoeller-tls-downgrade-scsv-00, it *is*
left to security trade-offs whether you'd rather see a handshake failure,
or accept the downgraded protocol even though the client and server should
have been able to negotiate something better.  The specification is written
to let the client make this decision, because such retry policies are
necessarily client-driven.  The specification currently does not explicitly
recommend that TLS implementations let the calling application influence
this policy (I certainly could add that, but then our specs don't typically
identify the many protocol configuration settings that can typically be
influenced by applications as such -- we're specifying protocols, not APIs
for using those protocols from applications).



> Another example for TLS version challenges are defective middle-boxes
> (Bluecoat seems popular for internet access from company networks):
>
> https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642


That's why the Security Considerations in my Internet Draft have this:

   Section 4 does not require client implementations to send
   TLS_DOWNGRADE_SCSV in any particular case, it merely recommends it;
   behavior can be adapted according to the client's security needs.
   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_DOWNGRADE_SCSV could be omitted for this particular

   protocol downgrade step.




> Yet another example would be the upgrade path for an installed server-farm,
> where you would get yourself into trouble if the existing server-farm
> causes clients to perform reconnect-fallbacks and trying to test
> a new implementation of the kind you suggest would cause occasional
> handshake failures for handshake where the first request went to an
> old server, and the reconnect fallback to the updated server.
> So for such a setup, this kind of feature would require a "flag day".
>

You mean something like the following, right?

- Broken servers support TLS 1.1 only, and will barf on a TLS 1.2
ClientHello.
- Fixed servers also supports TLS 1.2, and understand TLS_DOWNGRADE_SCSV.
- Connection are distributed to servers in a round-robin fashion, say.

You'd encounter a glitch in this scenario if a client tries a TLS 1.2
handshake to a broken server first, then retries with TLS 1.1 and
TLS_DOWNGRADE_SCSV and happens to hit one of the fixed servers so that the
connection attempt fails.  (There's no such problem if both connections go
to a broken server, or if the first connection goes to a fixed server.)
 So, for some proportion of cases, retrying clients wouldn't benefit from
their retries, and instead would encounter similar brokenness as those
clients that don't retry in the first place.

There's no requirement for a "flag day" (by which I assume you mean
changing the configuration for the entire server farm at once) if you roll
out fixed TLS 1.1 servers first (at any pace), and subsequently enable TLS
1.2 support (at any pace).




>   http://tools.ietf.org/html/rfc5288#section-4
>   http://tools.ietf.org/html/rfc6655#section-5
>
> Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight-
> forward, and the cipher suites (themselves) would exhibit the same
> security properties.  But this [...] prohibits clients from even
> proposing these cipher suites when they're doing a fallback, independent
> of what is causing the fallback.
>
[...]

> To really improve the situation, new protocol features (including
> TLS protocol versions >1.1) ought to be negotiated in a fashion that
> increases the amount of successful TLS handshakes for the entire
> installed base, and avoids the necessity for reconnect fallbacks--
> something that the majority of programmtic TLS clients do not
> even have.


I assume that those specs were written to disallow these AEAD cipher suites
for earlier protocol versions specifically to improve interoperability,
because a client wouldn't be able to indicate that it
supports TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 but not for TLS
1.1.  Assigning additional cipher suite numbers for essentially the same
cipher suites *with* support for earlier protocol versions might be
worthwhile.

Bodo