Re: [TLS] rfc7366: is encrypt-then-mac implemented?

[[e-mail] (Martin Rex)]

Christian Kahlo wrote:
> > > The last two paragraphs of
> > http://tools.ietf.org/html/rfc5246#appendix-
> > > E.1
> > > make that clear: "Thus, TLS servers compliant with this specification
> > > MUST accept any value {03,XX} as the record layer version number for
> > > ClientHello.".
> > 
> > OK. Fixed. Checked In. Deployed.
> 
> By the way this is an operational system. The server is PFS-only with
> ECDSA_RSA activated. RC4 and Camellia are not supported and 3DES is
> deactivated. TLS1.0 is supported but not enabled.

None of this matters.  Server that reject the Handshake because the
initial ClientHello on a new connection arrived in a TLS Record with
an outer { 0x03, 0x00 } protocol_version is *ACTIVELY* hurting
interop in an extremely serious fashion, and server misbehaviour like
this is the reason why the "downgrade dance" heuristics that current
browsers are performing.

The original TLS protocol provides a means for protected negotiation of
protocol features, and a regular/generic client that doesn't contain
any complex reconnect fallback ("downgrade dance") logic at the application
level will be using { 0x03, 0x00 } in the Record Layer for the initial
ClientHello.  This choice will provide out-of-the-box connectivity to
a few remaining old SSLv3-only servers, while simultaneously ensuring
that only newer protocol versions will get used with servers that
support newer TLS protocol versions.


A reason why even TLS clients that do not want to talk SSLv3,
would sensibly be using { 0x03, 0x00 } here, is that they can normally
expect to get an SSL alert in return if the server understands the
SSL/TLS record format.


-Martin