Subject: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 17:40:46 -0700

On Fri, Oct 17, 2014 at 2:56 AM, Bodo Moeller <[email-masked]> wrote:

> Brian Smith <[email-masked]>:
>
>> If version downgrades during False Start are to be tolerated, then at
>>
> a minimum the security considerations of this draft must point out
>> that the mechanism is simple to subvert (partially, at least) when
>> False Start is used.
>>
>
> Exactly, but the detailed recommendations should go into an updated False
> Start I-D instead; I can do that.  Specifically, that spec could say that
> if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
> SHOULD be disabled for that handshake. And then we'll also have to say that
> the client similarly should not use False Start with any protocol version
> for which it would send TLS_FALLBACK_SCSV in fallback retries (since
> otherwise the former recommendation wouldn't achieve anything.)  The
> TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
> reminder that allowing False Start with older protocol versions can be
> problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
> can't address.
>

I agree with you. However, please consider changing some of these SHOULDs
to MUSTs. As it is, every implementation already trivially conforms to the
current drafts, because all client implementations implement all the MUSTs
(the only MUST is that they MUST NOT send the TLS_FALLBACK_SCSV when
ClientHello.client_version is the highest version they support). That isn't
helpful.

Note that POODLE, or variants thereof, may apply also to TLS 1.0+
implementations. For example, back in 2010, I fixed a bug in NSS where NSS
did not verify all the padding bytes in TLS 1.0 records [1]. Thus, any
server that is using a version of NSS released prior to June 2010 is likely
vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled.
Further, note that the TLS 1.0 specification [2] does NOT say that
implementations must check the padding; that requirement was only added in
TLS 1.1 and TLS 1.2. Thus, an implementation could completely conform to
TLS 1.0 but still vulnerable to POODLE. Finally, even though the TLS 1.1
and TLS 1.2 specifications do say that implementations must check the
padding, it isn't necessarily the case that otherwise-working
implementations actually conform to that requirement, and there's no way
for the client to check that in a reliable, high-performance, and accurate
way.

Consequently, I think that:

1. Browsers must abandon the non-secure version rollback to versions prior
to TLS 1.2 completely.

2. The downgrade-scsv draft should be changed to say that implementations
MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version
indicates TLS 1.1 or lower if the client supports TLS 1.2.

So, I believe that your suggestion for client behavior is absolutely spot
> on. My point is just that the very same issue w.r.t. False Start and
> version downgrades exists if the client doesn't do any fallback retries --
> and those who implement such clients shouldn't have to read the
> TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
> into the False Start spec.
>

I agree that the False Start RFC should be updated to include this and
other considerations.

> Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
>>
> saying it is surprising that the downgrade SCSV doesn't prevent
>> version downgrades, and that should be fixed.
>
>
> Right. I'll mention that potential surprise with False Start in
> TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
> the False Start specification.
>

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 07:32:33 +0200

> indicates TLS 1.1 or lower if the client supports TLS 1.2.

Maybe, but note that this doesn't actually help against the concrete
problem with old buggy NSS servers (because these don't handle
TLS_FALLBACK_SCSV).

I think that an RFC 2119 "SHOULD" is right for this; if applications ignore
that recommendation willy-nilly, they could also ignore a "MUST". For
strong protection against bugs in old protocol versions, the only option is
to disallow those versions completely.

Bodo

---

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 23:21:50 -0700

> problem with old buggy NSS servers (because these don't handle

First of all, even that old version of NSS is not buggy, according to the
spec. My main concern isn't with old versions of NSS. My main concern is
that we do not know how many TLS 1.0 servers actually check the padding,
but we've assumed that all of them do, even though TLS 1.0 does not require
checking the padding.

Note that a 100% conformant TLS 1.0 implementation could add
TLS_FALLBACK_SCSV support exactly as spec'd and still be vulnerable to
POODLE if it doesn't check the padding in CBC-mode records. Again, I think
this is something worth adding to the security considerations of the
TLS_FALLBACK_SCSV draft.

For strong protection against bugs in old protocol versions, the only
> option is to disallow those versions completely.
>

Yes, but TLS 1.0 implementations can mitigate the risk, as most do, by
checking the padding conforms to the TLS 1.0 requirements.

And, so can SSL 3.0 implementations, right? Checking that SSL 3.0 CBC-mode
records conform to the TLS 1.0 padding rules is likely to cause some
interop problems, but those interop problems would be much less severe than
disabling SSL 3.0 completely, right? I checked and most implementations of
SSL 3.0 are following the TLS 1.0 padding rules in records that they send,
including IE6 on XP, AFAICT. It seems to me that that is a better solution
for websites that refuse to disable SSL 3.0 because they feel they need IE6
support, compared to switching to RC4-only for SSL 3.0. What do you think?

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 09:19:02 +0200

My main concern is that we do not know how many TLS 1.0 servers actually
> check the padding, but we've assumed that all of them do, even though TLS
> 1.0 does not require checking the padding.

While the spec could be better, it clearly does expect implementation to
check the padding. (The alternative reading, as far as I can see, would be
that checking the MAC isn't required either.)

> disabling SSL 3.0 completely, right?
>

Some implementations do indeed use TLS 1.0-style padding with SSL 3.0, but
not all do, and SSL 3.0 has too many other problems to be worth keeping
alive.

Bodo