MIME-Version: 1.0
In-Reply-To: <5449E969.9000800@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
 <5449E969.9000800@brainhub.org>
Date: Fri, 24 Oct 2014 11:58:47 +0200
Message-ID: <CADMpkc+cLJNMYZb4OqukM7qT1aPsqEmCF0JxOyuLYe=78BEcgQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11390932281ccb0506283a0d
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b8qcMEGRwlM0w-ghv13WAqnprtc
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Precedence: list

--001a11390932281ccb0506283a0d
Content-Type: text/plain; charset=UTF-8

Andrey Jivsov <crypto@brainhub.org>:

Client decides to drop to TLS1.1 (due to network glitch, etc). [...] The
> server MUST fail with inappropriate_fallback per sec 3.
>
> Is it a good idea to reject a more secure protocol than the server can
> possibly negotiate with this client?


In this case, the connection really fails due to the network glitch. If the
client wasn't attempting fallback retries, it would similarly fail. (This
could happen independently of the cipher suites that the server accepts.)

In the kind of hypothetical scenario that you describe, it indeed wouldn't
cause a reduction in security to accept the connection instead of failing,
but optimizing for corner cases like this one doesn't seem reasonable: it
necessarily would make the mechanism more complex overall.

(The server behavior that you describe also would be really odd. The CBC
cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more broken
in TLS 1.0 than in TLS 1.1. If the server *does* support one of the newer
protocol versions, why would it only support the most broken incarnation of
that cipher suite?

Also note that in the *specific* hypothetical scenario that you describe,
the server actually would accept the fallback retry: you said that TLS 1.0
is the highest protocol version supported by the server; this is not higher
than ClientHello.client_version in the TLS 1.1 retry, so the server
wouldn't reject.)

Bodo

--001a11390932281ccb0506283a0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Andr=
ey Jivsov <span dir=3D"ltr">&lt;<a href=3D"mailto:crypto@brainhub.org" targ=
et=3D"_blank">crypto@brainhub.org</a>&gt;</span>:</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Client decides to drop to TLS1.1 (due to network glitch, etc). [...]=C2=A0T=
he server MUST fail with inappropriate_fallback per sec 3.<br>
<br>
Is it a good idea to reject a more secure protocol than the server can poss=
ibly negotiate with this client?</blockquote><div><br></div><div>In this ca=
se, the connection really fails due to the network glitch. If the client wa=
sn&#39;t attempting fallback retries, it would similarly fail. (This could =
happen independently of the cipher suites that the server accepts.)=C2=A0</=
div><div><br></div><div>In the kind of hypothetical scenario that you descr=
ibe, it indeed wouldn&#39;t cause a reduction in security to accept the con=
nection instead of failing, but optimizing for corner cases like this one d=
oesn&#39;t seem reasonable: it necessarily would make the mechanism more co=
mplex overall.</div><div><br></div><div>(The server behavior that you descr=
ibe also would be really odd. The CBC cipher suites are more broken in SSL =
3.0 than in TLS 1.0, and more broken in TLS 1.0 than in TLS 1.1. If the ser=
ver *does* support one of the newer protocol versions, why would it only su=
pport the most broken incarnation of that cipher suite?</div><div><br></div=
><div>Also note that in the *specific* hypothetical scenario that you descr=
ibe, the server actually would accept the fallback retry: you said that TLS=
 1.0 is the highest protocol version supported by the server; this is not h=
igher than ClientHello.client_version in the TLS 1.1 retry, so the server w=
ouldn&#39;t reject.)</div><div><br></div><div>Bodo</div></div></div></div>

--001a11390932281ccb0506283a0d--