Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[Michael Clark <[e-mail]>]

On 23/1/15 10:33 am, Michael Clark wrote:
> However this is my thinking, which was modified by the comments of others.
>
> A).
>
>     1). Codify use of a "Supported TLS Versions Extension" with either
> a strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate
> SSLv3.0
>         * Advisory to recommend the record layer ClientHello version
> be fixed to the lower bound { 3, 0 } ; which there seems to be some
> consensus for
>         * In the case where the extension is echoed. i.e. supported,
> the record layer version is echoed by the server and signed in the
> handshake.
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance. i.e. All TLS implementations can benefit from it.
>
> And in TLSv1.3, where payload can be changed, and extensions can be
> mandated, without breaking backwards compatibility, it also makes
> sense to:
>
> B).
>
>     1). MUST Codify use of a "Supported TLS Versions Extension" with
> either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1
> } to deprecate SSLv3.0
>         * In the case where the extension is echoed. i.e. the lower
> bound is signed in the handshake.
>         * This provides administrators with a clear indication of
> supported versions and the ability to set their lower bound
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.
>         * Complete deprecation of SSLv3.0 would like be achieved by
> the time TLSv1.3 is in the wild.
>
>     2). MUST tighten the wording with respect to the ClientHello
> record layer and message layer versions
>         * Fix the record layer ClientHello version to the lower bound
> { 3, 0 } ; which there seems to be some consensus for
>         * This is TLSv1.0 through TLSv1.2 compatible via extension
> tolerance.


Based on Nikos's comment there needs to be a clarification on the
mitigation track (for TLSv1.0 through TLSv1.2) vs standards track (for
TLSv1.3) on whether the ClientHello "record layer" lower bound is { 3, 0
} or { 3, 1 } and this could potentially be different in TLSv1.3?

From my read, it seems in the time frame of current mitigations (SVSC in
the field or Nikos's "Supported Versions Extension" as a more elegant
forwards and backwards compatible version signalling mechanism). Nikos
was pushing on { 3, 0 } for a current lower bound (at the record layer)
for TLSv1.0 through TLSv1.2 as { 3, 1 } at the record layer in the
current time-frame *allegedly* causes dancing for a few remaining
upgrade recalcitrant servers. i.e. causing problems in the wild. This
was my read.

So the decision remains whether { 3, 0 } or { 3, 1 } is the "record
layer" lower bound in TLSv1.3; depending on whether mitigation
propagation has made provision for the lower bound to be raised to { 3,
1 } in TLSv1.3. Implementors tried { 3, 1 } and Nikos disagreed and said
this compounded the dancing issue. We proposed a compromise that is both
forwards and backwards compatible and it happened to match something
Nikos had previously proposed. It was to pin { 3, 0 } at the record
layer (essentially making the protocol major version the record layer
version as opposed to TLSv1.0 { 3, 1 } ; this is in fact a record layer
binary compatibility boundary) and listing "Supported TLS Versions
Extension" with { 3, 1 } as a mandatory lower bound (ignored by the
recalcitrant servers). This allows someone unwise to add SSLv3 { 3, 0 }
to "Supported Versions" if they want to support it, but most importantly
lets you signal { 3, 1 } as a signed lower bound in any TLS version (1.0
through 1.3) while showing { 3, 0 } at the record layer for
compatibility. This seems ideal.

I understand this is issue is already mitigated where it is important
(using SVSC or other tightening mechanisms) rather the mechanism is
completely not standardized.

Sorry I am on the temporal track, not the standards track. I'll read
these pull requests:

  https://github.com/tlswg/tls13-spec/pull/105
  https://github.com/tlswg/tls13-spec/pull/107

Thanks for clarifications.