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

[Brian Smith <[e-mail]>]

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

> Brian Smith <[e-mail]>:
>
>> 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