From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 28 Jul 2015 17:41:58 +0200
Message-ID: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6545367.A87tjg4WYV";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DLm98TfNVYOwf6X3cGjXEhdwUR0>
Subject: [TLS] No cypher overlap (was: ban more old crap)
Precedence: list

--nextPart6545367.A87tjg4WYV
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

I see one possible problem with TLS1.3 not being a superset of TLS1.2.


Consider the following:
  Server which supports TLSv1.3 but is configured to accept only AES256=
=20
ciphers.
  Client which advertises TLSv1.3, but no support for AES256-GCM. The c=
lient=20
advertises also CBC ciphers (both AES128 and AES256) as it wants to be =
able
to connect to legacy servers too.

Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, o=
r=20
should it be aborted?

I think we should go for continue connection with downgraded protocol, =
but=20
explicitly say that it may not happen if the negotiated ciphersuite wou=
ld be=20
DES, RC4, export grade...

That would allow us to reiterate in the TLS1.3 spec that they are a big=
 no-no,=20
and that if you claim support for TLS1.3 you should never negotiate the=
m with=20
a similarly modern peer.
=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
--nextPart6545367.A87tjg4WYV
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

iQIcBAABCgAGBQJVt6LGAAoJEJKo0bgB0vX1FYsP/308kmgfqtGQdxcgIcGvpINM
DmFYNFl8Z+VYpM13PrZyKSyod6I7OFvQZk+rjUt92bkENGFS7zztrAuCoqiqxetu
oFHf+TAS07IxK/47QsoFoV9U8/2g+F6asRJ1rzuP1/4BSXcWQGVb4W8I1cL67UD8
MVZj25g/A5NTU4mZTARBAehl0JmqP8tkO51AtD+nagSXv1nX3vN96iVDc58/Bypg
OeKSy/To8bJIfS9flU3/3c6NRS0Bab6sZJq3WOQxLKAz2GYHD2e9sicKnWt3sJ/K
WtChpzV4ZscK+e4O2YNrVBF55MUDB0lkGoEhKiOILUbML/VaCqqVVGXqfXPjpXFi
NjVVmQQ/KxqYVrG4z0Ku9nUmZp9l3dtDeM63VHy5Hf+kOvl8KH5htHT1YguCUVm6
4BkSAxcP3NbOTWxPRBLyWFtNizMoSW8Ki7UXjQ3c6sLWPrA8jLKBSlCvce3/MXOf
1lGhRkXS57Q3n/8mto0hVOC9sRAmG5gE40XfUTZepUBrWsP26X+bg3qEDhgRU7aU
GZHUYgK3v5bOD4PdYHPXwbmO++m/0706W9/GNzntq3sb5wUGcmh0qJ3zfhmlfrWS
BpB3qOEErEJBoD6ea3g7VZwso3KIVp11WL85zZ+N51X+wxb2YeUPkXsIMLwLV++L
DVc0PuQZZayXvpYqnQ37
=BdSE
-----END PGP SIGNATURE-----

--nextPart6545367.A87tjg4WYV--