From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 29 Jul 2015 11:59:41 +0200
Message-ID: <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <20150728160154.GU4347@mournblade.imrryr.org>
References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com>
 <20150728160154.GU4347@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2165947.i50fGD6tct";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zL-16PK0jGLV1VFpbBoxFpV22HE>
Subject: Re: [TLS] No cypher overlap (was: ban more old crap)
Precedence: list

--nextPart2165947.i50fGD6tct
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
> On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:
> > I see one possible problem with TLS1.3 not being a superset of TLS1=
.2.
> >=20
> > Consider the following:
> > Server which supports TLSv1.3 but is configured to accept only AES2=
56
> > ciphers.
> >=20
> > Client which advertises TLSv1.3, but no support for AES256-GCM. The=
 client
> > advertises also CBC ciphers (both AES128 and AES256) as it wants to=
 be
> > able
> > to connect to legacy servers too.
> >=20
> > Should such a connection end up with TLS1.2 with AES-CBC ciphersuit=
e, or
> > should it be aborted?
>=20
> We already see a similar dilemma with clients that (artificially)
> support only SSLv2 ciphersuites, but advertise TLS protocol versions.=

> OpenSSL will first choose a common protocol (TLS 1.x) and then fail
> to find any shared ciphers.  To complete the connection, the client
> must explicitly request only SSL 2.0.  There is at present no
> filtering out of protocol choices for lack of compatible ciphers.
>=20
> > I think we should go for continue connection with downgraded protoc=
ol, but
> > explicitly say that it may not happen if the negotiated ciphersuite=
 would
> > be DES, RC4, export grade...
>=20
> In that case, it should be said that a client MUST NOT advertise
> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
> (or perhaps less restrictive at least one TLS 1.3 compatible cipher).=


MTI does not mean Mandatory To Enable

> Otherwise, there'll be lots of clients whose TLS libraries advertise
> 1.3 (just because they implement the protocol), but whose cipher
> configuration includes only TLS 1.2 (or lower) suites (because the
> application configuration has not been updated).

yes, that's what I'm afraid of

> Punishing those clients by having servers abort the handshake is
> a bad idea.  The right outcome is use of TLS 1.2, whether because
> client implementations of 1.3 need to check that adequate cipher
> suites are available, or because servers negotiate 1.2 when 1.3
> is impossible.

neither clients nor servers are required to support (have them enabled)=
 all=20
ciphersuites defined for TLS1.3, so there is always chance for no commo=
n=20
cipher between them

=2D-=20
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi=
c
--nextPart2165947.i50fGD6tct
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJVuKQNAAoJEJKo0bgB0vX1p3kQAIVuCbD+kmxhr3P4dZDD1QWr
pqQJI5YNJIReOg/ttQ/Vq94g9j0kRUt7QTrTDNTYt6X566De2gLEHitKFR53M4v8
kVqp2Ch2iH57yk49ChDUb89y6ORAa2uH063TB7kt7JrD1P+Nn9jFssUz4hvY/HX4
HIX8M6ytxjn62ELtkM9d/J/Qd0KFlAnwgHEagdEU0CYydxHzV5GRR/wKxfzU7+y/
FDd1V+XK33DQN99Hs8bb88CX/2OjZKDzGJTUAO3RAHzkIVWdW4XAleD0dgqhLhKU
Hq1KLsU+a20Tg4l4F71CqUmXqULotPyk0y6eoC++yMYu/G0QTynqG/rOiDpXA+aJ
3ARypBsAZD6anyMOWKzOW9ttEnlPprxTxZUv+aq0Du58KTH0wPVML8DE+je0+Chf
0Zf3qkM4zSxdNYwH4DNVZnbXAaf5QgZcEiuCP7sMQiye69picSutw914OGjgguEz
k8KcL8wbN1YW/CWfXaHVW9MPjovIOZs7y6GFFmJlljcS9xpisxBU4XpaeFqgkwyj
Iu5KGWhT4d/olIrlHrhMYb20o3aVFLquM1KBVl1e6hQd6b5nVq+FMgroKMEByAqV
F7BGkF06NFttOQf3rZETYAO3+7DpApAL9xHyiT14Wam+L8ET0uA7bmQqHNuGvr6X
XXHQSukUUpLDMRarLUmY
=XnC+
-----END PGP SIGNATURE-----

--nextPart2165947.i50fGD6tct--