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]>]

Hi All,

* Very interesting stats. Are they independently verifiable?

* Very interesting facts on the specification ambiguity regards
  ClientHello "message Layer" version and "record layer" version
  SCSV might not have existed had implementations followed E.1.

- Agree with not adding SCSV to the proposed standard assuming
  the accuracy of these stats (even if I wrote SCSV myself I would
  stand corrected).

+ SCSV served a purpose of a mitigation while clients downgraded
  due to version upgrade intolerant servers. It may have served its
  purpose. Don't downgrade and there is no attack vector (1.6% servers).


Recommendations:

= Based on these numbers, it appears that clients MUST avoid downgrade
  when sending their highest ClientHello "Message Layer" TLS minor
  version number; given the TLS 1.3 ClientHello "Message Layer" minor
  version upgrade intolerance is 1.6% (for the Alexia top 1 million).

= ClientHello "Message Layer" TLS minor *version upgrade tolerance*
  intrinsically mitigates downgrade attacks.

= Appendix E.1 should state that servers MUST tolerate higher
  ClientHello "Message Layer" TLS minor protocol versions rather
  than recommend it and recommends the lower bound on the record
  layer TLS minor protocol version. It states:

  "No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document."


Reasoning:

= Based on these findings, we could safely tighten the spec:

   During non resumed handshake the ClientHello record protocol
   version MUST indicate the clients minimum supported TLS version
   and the ClientHello message layer TLS version must indicate the
   maximum supported TLS version. The ClientHello TLS version MUST
   be greater than or equal to the record protocol TLS version.

= TLSv1.3 implementations could remove SSLv3.0 support such that
  the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
  instead of { 3, 0 } which is mentioned in the Appendix as a
  "typical value" and the maximum "message layer" version a server
  accepts is specified as { 3, XX }. A TLSv1.2 client could send
  { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
  in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
  with protocol major/minor best practices for binary changes and
  backwards compatibility. i.e. no binary incompatible changes in minor
  versions. Just raise non-compliance with Appendix E.1 as a bug.

= Ambiguity only exists for ClientHello.

= ClientHello Message Layer TLS version tolerance; no upper bound
  for the *message layer* TLS "minor" protocol version) is protective.
  { 3, XX } or even { 4, 0 } for TLSv1.3 as I reason below.

= ClientHello Record Layer TLS version intolerance; strict lower bound
  for the *record layer* TLS "minor" protocol version) is protective.
  Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
  (from an evolutionary perspective).


Issues (beyond the scope of TLS spec according to Appendix E.1):

= The issue is there is an (implicit and variable) *range* of
  acceptable versions; based on different policy of various clients
  and servers; caused by recommendations for deprecation of earlier
  protocol versions; most importantly SSLv3.0 (predictable IV); and
  the timing of roll outs of protocol upgrades to clients and servers.
  The deprecation, or lower bound needs to be made explicit.

= The notes in Appendix E.1 considers a "backwards compatibility"
  mechanism but do not make explicit the "deprecation" mechanism.

= Forward and Backwards compatibility (backwards binary compatibility
  through careful structure addition, unknown extension tolerance,
  minor version upgrade tolerance and unknown cipher suite tolerance
  should be preserved within "minor" protocol versions. This matches
  best practices for protocol discipline. Reconnecting with a lower
  version after alerts should only be attempted for deprecated
  protocols (SSLv3.0) after going through a "proceed with caution"
  screen. e.g. new minimum at the record layer of { 3, 1 }. You
  then only have "user agreement" to downgrade, or based on stats
  you can make { 3, 1 } the new minimum.

= It raises the issue that the TLSv1.3 spec specifies major version
  tolerance for the "message layer" ClientHello e.g. { 3, 1 } { 4, 0 }
  for at least "one major version" to prevent future downgrade attacks
  with a new major protocol version upgrade. This would build into
  TLSv1.3 the provision to introduce a new major version without
  being attacked.

= This would mean that a new major protocol version would need to
  define an embedding for its ClientHello within the record protocol
  of the previous major version (verbose legacy) as well as defining
  its new ClientHello format. A putative TLSx { 4, 0 } could send a
  verbose ClientHello "message layer" { 3, 1 } { 4, 0 } containing a
  legacy "combinatorial explosion" of cipher suites and already
  widely supported curve point formats, etc, SNI ext and optimistically
  embed its { 4, 0 } Hello data in an extension then learn/cache the
  version of servers and subsequently sends concatenated new Hellos
  { 4, 0 } { 4, 0 } for fast starts using a lean "profiles" system
  with profiles and pre-negotiated cryptographic primitives. Servers
  tolerant of ClientHello message layer major version upgrade is also
  protective given a mandate that major version upgrades define an
  embedding of their ClientHello (yucky verbose cipher suites) for
  the previous major protocol version. Doable.

= Yes. AEAD-AES-GCM is the cipher suite you would keep to maintain a
  bridge to TLSv1.2. Most of the other 304? are not AEAD.

= Do you want to specify more cipher suites at present? I argue below
  that based on verify_data that it may be a bad idea. See below
  TL;DR --- related but forward looking --- and the missing
  specification of verify_data_length in all cipher suites including GCM


On 21/1/15 5:16 pm, Yoav Nir wrote:
> Thanks
> 
> In that case, I think my implementation would fail with (1.3,1.3). Since
> I can’t know what changes TLS 1.3 made to the record layer, I can’t be
> sure that I understand what I’m parsing. Perhaps those bytes that I
> thought were the ClientHello are actually some new fields that were
> added to the record header.

Reasoning aloud.

You can if we know we are adhering to strict minor protocol version
binary compatibility rules. i.e. reasoned structure addition and
length prefixes, unknown extension tolerance and higher Hello version
tolerance. The "rule of thumb" is to only break binary compatibility
on major version changes.

If you are a 1.2 server and you receive a 1.3 ClientHello
{ 3, 1 } { 3, 4} and reply with a { 3, 3 }, { 3, 3 } ServerHello
then tolerant behavior (tolerance to higher ClientHello minor version
is protective) and is acting on the presumption that the client accepts
the older version specified in the record layer as you mention.
Likewise client intolerance to lower than ClientHello record layer
TLS version in ServerHello is also protective.

This accords with Appendix E.1 and it makes sense to avoid round trips,
and this intrinsically mitigates the downgrade attack vector. An alert
due to version upgrade intolerance in fact *opens* the attack vector.

If you are a 1.3 server, your server knows as with other TLS versions
that the ClientHello and ServerHello format will be designed with
"forwards compatibility" so you would not have any problem replying,
with the version you support, either 1.3 (after it is specified) or
1.0, 1.1 or 1.2 in response to a 1.3 ClientHello (Appendix E.1) with
1.0 at the record layer. Sure, if you reply with 1.3 now then a client
will abort. The version tolerance as per Appendix E.1 mitigates
downgrade tampering, as intolerance (or non compliant implementations)
lets your security be downgraded, by the "work-around" reconnect.
The implementations that are not version tolerant are not compliant
and stopping "work-around" reconnect improves things.

There is also TLS extension tolerance and cipher suite tolerance
(which SCSV relies on) to consider.

    https://bugzilla.mozilla.org/show_bug.cgi?id=689814

The core issue is Appendix E does not make explicit a protocol version
deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
lower bound of { 3, 1 } for the record layer TLS version in the
ClientHello as they are the same major version (in reality).
The fact that SSLv3.0 has partial record layer binary compatibility
is a red herring. We should notionally subtract { 2, 1 }.
SSLv3.0 is past the used by date.


Thought experiment.

The crux is the server lacks the information (through ambiguity of
specification) on the "range" of older versions supported by the
client. The reality is as Yoav mentions is the record layer has become
an adhoc signalling mechanism of the lower bound. Without this knowledge
we might invent an extension for the ClientHello to signal a list of
earlier versions in a "Compatible Versions Advisory Extension"
to signal to older servers that the client also accepts these.
This would provide for deprecation once servers are *upgraded* with
the "Compatible Versions Advisory Extension" extension. However the
problem is not with servers that upgrade. It's the 1.6% that have not
been upgraded. So yes. This is also equally as redundant as SCSV if
the record layer TLS version in the ClientHello is the lower bound.
The real issue is the client has to stop talking SSLv3.0.
i.e. There is no point to upgrade a server with this mechanism, rather
you need to start blocking the 1.6% servers that are not upgrading,
or at least prompt the user before downgrading a connection. i.e.
The proceed with caution screen. Simply becoming intolerant of
"message layer" version intolerance makes you no longer susceptible
to downgrade attacks.

This or any other advisory signalling mechanism becomes redundant
assuming downgrades should never happen within the same minor protocol
version and that the ClientHello record layer lower bound is { 3, 1 }
and the message layer ClientHello version upper bound is say { 3, 99 }.

End thought experiment.


Conclusion: Ipso facto, SCSV is redundant if servers implement version
tolerance as per the spec and clients don't try downgraded connections.


That said, SCSV was a valuable temporary fix to prevent downgrade
workarounds while lots of SSLv3.0 and/or version intolerant servers
were still in the wild. According to stats, this is no longer the case.


Based on those stats, if browsers adopted a common strategy of not
attempting to re-connect at lower TLS versions than what they signal
at the record layer, and servers followed Appendix E.1 version
tolerance, we would gain downgrade tamper resistance without any
signalling mechanism, and servers that were version intolerant would
naturally end up being upgraded when enough new clients adopted
Appendix E.1 guidelines. The small fraction of servers will get
upgraded if they have any customers.

If the recalcitrant servers are doing eCommerce, then we would be
doing them a public service. Give them 90 days and cut the cord on
SSLv3.0. They can always put a proxy in front :-D


> If the record layer version exceeds what the server supports, I think it
> wouldn’t be prudent to reply with anything but an alert. Many
> implementations treated the record layer version in the ClientHello as a
> minimum version number. Yes, I know this goes against a MUST requirement
> in appendix E.1 or RFC 5246, but as that appendix says, this is behavior
> that is often implemented.


I agree. If clients become intolerant of implementations that are not
version tolerant (compliant with the spec) then there is no need to
attempt to re-connect, and thus become vulnerable to downgrade attacks.
The nuance that is missing is clear text on guidance for the constraints
on the "record layer" and "message layer" TLS versions for the
ClientHello. Thanks for making it clear. I wasn't aware of the
ClientHello version ambiguity.



TL;DR --- related but forward looking ---


SNI is being sent to many servers that don't support the SNI extension
but most servers are tolerant of unknown extensions? I am now curious
about extension tolerance.

1). Q. Is there a similar data for extension intolerance?
2). Q. Is extension tolerance on the flip-side an attack vector?
       i.e. appending unknown extensions to the handshake to forge
       the 96-bits of verify_data?


There is a related threat analysis of extension tolerance forgery
potential; version and extension tolerance seem to be the status.
I found anecdotal mention from Ivan Ristic related to a small number
of servers that are SNI extension intolerance. Extension tolerance
however provides verify_data forgery potential. The question was
whether it is a credible threat. The answer was not right now.
Perhaps not this year, but certainly in the time-frame of TLSv1.3.


3). Q. From TLSv1.2 rfc5246, cipher suites can specify a longer
verify_data. Do any of them do so? neither rfc4492 (ECC) or rfc5289
(AES-GCM) mention verify_data length.

  In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

As discussed earlier, using specially crafted extension data and
exploiting extension tolerance to forge verify_data is bounded by the
probability of a verify_data collision with a 16K message (2^14) which
with 96-bits verify_data (2^96). This is tractable at quantum scale (in
the TLSv1.3 timeframe) but not a present credible thread (unless there
is information to the contrary). The probability is (if my math is
correct?):

    handshakes * (2^14) / (2^96)
    handshakes / (2^82)

This is not a credible threat right at this moment, but I believe it
should be addressed in TLSv1.3. i.e. 96-bits doesn't offer enough
handshake forgery protection for the next 10 years.


4). Q. Is there consideration in TLSv1.3 to decouple verify data from
the cipher spec (given it is in practice decoupled) and extend it?

>From master https://github.com/tlswg/tls13-spec/draft-ietf-tls-tls13.md

  In previous versions of TLS, the verify_data was always 12 octets
     long. In the current version of TLS, it depends on the cipher
     suite. Any cipher suite which does not explicitly specify
     verify_data_length has a verify_data_length equal to 12. This
     includes all existing cipher suites. Note that this
     representation has the same encoding as with previous versions.
     Future cipher suites MAY specify other lengths but such length
     MUST be at least 12 bytes.

Based on the current wording, all cipher suites would need to be changed
to increase the handshake integrity, which gives one pause
to consider wiping them in TLSv1.3, or only offering the AES_GCM
subset with different operational semantics (to allow for backwards
compatibility) with respect to verify_data if TLSv1.3 is negotiated,
and then add new cryptographic primitives through extensions as is
already done with ECC curve points, etc or profiles. I know a lot
about combinatorial explosions. TLS already has one. What about
only having three of four cipher suites?

  TLSX_XKEX_XVERIFY_XAEAD = { ?, ? }

  "Supported Elliptic Curves Extension" {}
  "Supported Point Formats Extension" {}
  "Supported Key Exchange Mechanism Extension" {}
  "Supported Certificate Verification Algorithms Extension" : { }
  "Supported Authenticated Encryption Algorithms Extension" : { }
  "Supported Signature Algorithms Extension" : { }

or

  TLSX_PSK_XPROFILE = { ?, ? }
  TLSX_ECDHE_RSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_ECDSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_EDDSA_XPROFILE = { ?, ? }

  "Supported Profiles Extension" : { ssf112_embedded_r1 }

This gives you a TLSv1.x embedding with extensions and a mechanism for
a short short negotiation with a newer TLS server that uses
prenegotiated labels and makes these now widespread primitives
part of the new mandate.

This approach was alluded I think by Watson and or others (apologies
if I am wrongly attributing this). I don't see why within TLSvx.x,
that cipher suites could be eliminated, and servers could advertise
"cryptographic primitives" in extensions, as an embedding in TLS1.x
and/or use a concatenated negotiation for profiles where all of the
primitives have been pre-negotiated against specified profiles.
The extension embedding relies on protection for "verify_data".
i.e. solving the verify_data forgery attack vector, but most
implementations are already extension tolerant. It is bounded.
Sending profile labels to indicate support of a predefined table of
primitives just requires the Server to tell you which primitives it
selected from the list it knows you support.

Using more extensions pushes onto the handshake sign, encrypt, verify
mechanism. i.e. so that the minimum RSA, PSK or ECC/EdDSA can protect
must be >= 128-bits of verify_data in a maximum 16K handshake messsage.
With a "profiles" or "labeled" primitives approach servers could
distinguish between embedded and desktop. i.e. servers can prohibit
certain operations. Often an embedded device is used for second factor
auth or recovery for a desktop profile device.

Cipher Suites are not necessarily wrong. They were right when there was
about 32 of them. 304 changes things. Evolution...

Michael.