Re: [TLS] An SCSV to stop TLS fallback.

[Bodo Moeller <[e-mail]>]

> > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.
>


1. Why don't you also specify a TLS extension, which can be used when
> we fall back to a lesser TLS version (but not SSL 3.0)?
>
> I assume specifying only a SCSV is for simplicity.
>

Yes, this is for simplicity and efficiency: we need a SCSV codepoint anyway
for fallback cases that can't use extensions, and if we have that, we'd
gain nothing by sometimes sending a (4-byte) extension instead of a
(2-byte) SCSV.  (Unlike RFC 5746's TLS_EMPTY_RENEGOTIATION_INFO_SCSV, the
new TLS_FALLBACK_SCSV isn't just a special case of a more general
extension, and we also don't require any information back from the server
that would require using the extension mechanism.)



> 2. I don't understand why you want the server to report an
> inappropriate fallback only if the client drops below the server's
> highest supported version.
>
> This means an inappropriate fallback is not always reported to the
> client, or it is reported to the client only after multiple fallbacks.
>
> For example, suppose the server supports TLS 1.1 and the client
> supports TLS 1.2.
>
> If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
> Reset (this middle box behavior was observed, not hypothetical), the
> client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
> but the server will then finish the handshake successfully.
>
> On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
> ServerHellos and injects a TCP Reset, the client will retry twice,
> first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
> Although the ClientHellos in both retries have the fallback SCSV, the
> server will only respond with an inappropriate_fallback alert to the
> second retry.
>
> I think the draft should explain the rationale for this less strict
> server behavior.
>

I'm afraid that I'm not entirely sure I understand what your concern is.

In the second scenario (TLS 1.2 and TLS 1.1 both blocked), the server will
only respond with an inappropriate_fallback alert to the second retry --
but it also wouldn't have a chance to respond to the first retry because it
doesn't see it, due to the middle box aborting that TCP connection.  So no
one would gain anything from sending that alert.

Now let's look at the first scenario (TLS 1.2 blocked by the middle box and
also not supported by the server): in the retry using TLS 1.1, the server
does not send the inappropriate_fallback alert because the client is only
falling back to the TLS version that should have been negotiated anyway: so
this fallback isn't "inappropriate" -- it's annoying from a protocol point
of view (and will typically have a latency impact), but that's just
inherent to the fallback strategy -- the client implements that strategy to
improve interoperability, accepting that protocol overhead.  Whether the
problem for the original connection attempt is caused by the actual
server-side TLS implementation or by something in between should be
irrelevant.

Moreover, if servers were to reject connection attempts with
TLS_FALLBACK_SCSV arriving in their native protocol version, this might
cause a new interoperability nightmare in the future.  Current server
implementations will generally be tested with TLS 1.2 clients, but not
necessarily with clients that send a version number such as 0x03 0x04 (TLS
1.3) or 0x04 0x00 (TLS 2.0?).  They are broken if they don't support that,
but preventing such broken servers from getting rolled out is outside of
the scope of, and not in the power of, this specification.  While I hope
that version intolerance problems can be addressed successfully (thus
rendering TLS_FALLBACK_SCSV irrelevant in practice -- servers will still
need the logic for it, but ideally clients would never actually send it),
that's pretty much orthogonal to this Internet-Draft.  I wouldn't want to
risk arriving at a situation where the server-side logic for
TLS_FALLBACK_SCSV becomes a hindrance for rolling out *new* TLS protocol
versions.

I hope that makes the rationale clearer.  Let me know if it doesn't, though.

Regarding making the draft clearer, I'm considering adding two or three
example cases to the Internet-Draft to discuss how and why
 TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.




> 3. In the Security Considerations section, we have:
>
>    However, it is particularly 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.
>
> It would be nice to name the weaknesses and workarounds explicitly.
> The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
> by record splitting, so I assume that's not the weakness you're
> referring to. Are you referring to the CBC padding timing attacks?
>

Right, I guess this is a little *too* thin on details.  I wanted to avoid
including a snapshot of currently known problems in currently relevant
ciphersuites, which would only distract from the more generally useful
simple mechanism specified in the Internet-Draft (and seems more suited for
a separate BCP document) -- however, if I choose to touch on particular
problems, I'd better say what those are :-)

The specific problem for CBC ciphersuites in SSL 3.0 is that block padding
is not completely specified.  As of TLS 1.0, three-byte padding (say) will
be of the form 0x02 0x02 0x02, but in SSL 3.0, the first two bytes are
allowed to have any value.  Accordingly, SSL 3.0 (unlike TLS 1.0) does not
require the recipient to validate the padding that it receives.  It has
been known for at least ten years (http://www.openssl.org/~bodo/tls-cbc.txt)
that this results in cryptographic insecurity in the presence of an active
adversary.

Unlike the other CBC ciphersuite weaknesses that have more recently made
the news, this problem is supposedly mostly irrelevant because SSL 3.0 is
way more obsolete than TLS 1.1 -- unless you allow an active attacker to
downgrade your connection to SSL 3.0, that is.  If you actually use SSL
3.0, there is *no* backwards-compatible remedy.  All you can do is prevent
unnecessarily falling back to SSL 3.0 (such as by using TLS_FALLBACK_SCSV).



>
> Also, it seems that the main problem with downgrading to SSL 3.0 is
> the loss of features and cipher suites that require TLS extensions,
> such as Server Name Indication and ECC cipher suites. You already
> mentioned that in the Introduction section. If the loss of these
> features and cipher suites degrades security, it should be mentioned
> in the Security Considerations section as well.
>

Good point, this clearly is an essential feature less in that particular
downgrade.



> Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
> to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
> record splitting workaround is effective). Perhaps these should also
> be mentioned.
>

I'm not that sure about this one given ongoing discussions about supporting
(at least certain) AEAD ciphersuites before TLS 1.2, and given that (as
discussed above) I want to avoid including a snapshot of current security
problem details, which seems best left for a separate BCP document that can
be updated as needed.  (There are several candidate documents in progress;
see here and wpkops.)

Bodo