Re: [TLS] consensus on backwards compatibility changes

[Michael Clark <[e-mail]>]

On 13/2/15 6:14 am, Dave Garrett wrote:
> PR#107 rebased. I believe all comments have all been addressed.
>
> https://github.com/tlswg/tls13-spec/pull/107/files
>
> To recap the changes:
> * ClientHello record layer version fixed to {3,1}
> * other record layer versions explicitly required to be negotiated version
> * note some security considerations & other suggestions from Brian
> * some editorial fixups
> * cite RC4 prohibition draft in backwards compatibility
> * explicitly forbid ciphers <112 bits for backwards compatibility
> * added the line:
> "If an implementation negotiates usage of TLS 1.2, then negotiation of cipher
> suites also supported by TLS 1.3 SHOULD be preferred, if available."

Comments as an observer.


1). Contention on setting the ClientHello record layer version to { 3, 0
} or { 3, 1 } in TLSv1.3

-: The version of the protocol being employed.  This document
-  describes TLS Version 1.3, which uses the version { 3, 4 }.  The
-  version value 3.4 is historical, deriving from the use of {3, 1}
-  for TLS 1.0.  (See {{record-layer-1}}.)  Note that a client that
-  supports multiple versions of TLS may not know what version will
-  be employed before it receives the ServerHello.  See
-  {{backward-compatibility}} for discussion about what record layer
-  version number should be employed for ClientHello.
+: The version of the protocol being employed in the current record.
+  TLS clients MUST set this version to { 3, 1 } for the initial ClientHello.
+  For the ServerHello and all other TLS records this MUST be equal to the negotiated version.


* In support of https://github.com/tlswg/tls13-spec/issues/113 and SSLv3
deprecation with haste
* Observe approximate consensus for TLSv1.3 implementation to not
negotiate protocol versions lower than TLSv1.0 with >= 128 bit cipher suites
* Text mentions information leakage. Argue that sending { 3, 1 } { 3, 4
} qualifies as information leakage.
* Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to
negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower
bound.
* Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded.
* The record layer version is not to be conflated with the minimum
negotiated TLS protocol version (from the same reasoning we deduce this
as information leakage).
* If a server sees ClientHello { 3, 0 } { 3, 4 } it knows the
ClientHello binary structure changes are additive since { 3, 0 } as it
is the record layer binary compatibility boundary.
* Given TLSv1.0 is a best practice for a protocol lower bound (separate
from TLSv1.3); then a TLSv1.3 client can safely assume servers will be
extension tolerant with ClientHello { 3, 0 } { 3, 4 } .
* Argue that setting the record layer version to { 3, 0 } leaks less
information given it is the record layer binary compatibility boundary
(not to be conflated with the minimum supported TLS version).
* Observation is that { 3, 0 } { 3, 4 } at the record layer would not be
incompatible with a client not supporting versions lower than TLSv1.0 {
3, 1 }
* If TLSv1.3 ClientHello is { 3, 1 } { 3, 4 } then so be it; however not
pivoting record layer version on backwards incompatible binary changes;
leads to { 3, 2 } { 3, 5 } and more information leakage.
* The fact that an SSLv3.0 server can parse the first part of the
ClientHello is not relevant to the choice of record layer lower bound
for the TLSv1.3 ClientHello.

Please note these as observations not recommendations. If there is
approximate consensus for { 3, 1 } at the record layer then I am in the
minority on the *pinned* value; prefer it to the minimum supported
backwards compatible record layer version; given an alert indicates a
buggy server. Please do not read this as support for SSLv3 backwards
compatibility.

Flip side:

* { 3, 1 } can be regarded as the binary compatibility pivot point due
to its extension support. In that case I favor { 3, 1 }
* The only argument for { 3, 0 } supports servers that are tolerant of
unknown data after the compression methods (in addition to cipher suite
tolerance).

Flip side:

* This tolerance is not a bug. TLS requires extension and version
tolerance as it is the forwards compatibility mechanism
* This is unknown hello data in view of SSLv3.0 servers that are not
even going to be supported
* { 3, 0 } leaks less information no matter what the protocol lower
bound of the client is

Conclusion

* Would rather accept ClientHello { 3, 0 } { 3, 5 } and send ServerHello
{ 3, 4 } { 3, 4 } and not have ClientHello { 3, 0 } { 3, 5} create
alerts that lead to downgrade attack vectors
* independently from the choice of site operators and clients to drop
support for SSLv3.0. i.e. pin the ClientHello record layer at { 3, 0 }
* Not in favor of pinning ClientHello record { 3, 1 }. { 3, 0 } should
be allowed.
* BCP 188



2.) "Negotiating with buggy servers"

+### Negotiating with buggy servers
+
+Some server implementations are known to implement version negotiation
+incorrectly. There are buggy TLS servers that simply close the connection
+when a client offers a version newer than it supports. Also, it is
+known that some servers will refuse the connection if any TLS extensions are
+included in ClientHello. Interoperability with such buggy servers is a complex
+topic beyond the scope of this document, and may require multiple connection
+attempts by the client.



* Primary observation. This section is at odds with the consensus for
TLSv1.3 implementation to not negotiate anything lower than TLSv1.0 { 3,
1 } with >= TLSv1.2.
* While the protocol lower bound may not be in scope for the TLSv1.3
spec; the security concern for bugger servers should be; a small number
of buggy servers lead to clients with attack vectors
* Buggy servers should not be named or supported in a security protocol
draft.

As an observer I would prefer to see this text changed from this:

    "and may require multiple connection attempts by the client."

to something like this:

    "and may require multiple connection attempts by the client, however
it is NOT RECOMMENDED that clients make multiple connection attempts as
this provides a vector for downgrade attacks"

or change the title to:
  

### Negotiating with version and extension intolerant servers