From: Hubert Kario <hkario@redhat.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 23 Jul 2015 19:11:38 +0200
Message-ID: <3105634.KntybK3qFp@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <201507231143.46288.davemgarrett@gmail.com>
References: <201507221610.27729.davemgarrett@gmail.com>
 <1724827.ajpDBsKllU@pintsize.usersys.redhat.com>
 <201507231143.46288.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart55302262.phjt5pjf2m";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qI6Of9LDzTTURwC9m2nD_MMSyag>
Cc: tls@ietf.org
Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
Precedence: list

--nextPart55302262.phjt5pjf2m
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more co=
mplex
> > mechanism to server configuration when the existing situation is
> > incomprehensible to many administrators won't help (and even many p=
eople
> > that write the various blog posts about "how to configure SSL [sic]=
 in
> > httpd" clearly haven't read openssl ciphers(1) man page)
>=20
> We should just get more serious about banning old crap entirely to ma=
ke
> dangerous misconfiguration impossible for TLS 1.3+ implementations.

there are valid use cases for both aNULL and eNULL
at the same time 3.5% of Alexa top 1 million will negotiate AECDH, some=
how I=20
doubt this many use it knowingly when ADH has just 0.2% market share

TLS is a universal protocol, that means that something that is a danger=
ous=20
misconfiguration in one threat model is entirely valid and good configu=
ration=20
in other

IoT and cloud computing will create a market for an implementation that=
 is=20
compatible with many threat models

> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
>=20
> How about we stop being fuzzy? I'd like to make it "MUST" use AEAD wi=
th all
> TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use D=
HE or
> ECDHE for ALL connections, even back to TLS 1.0, or abort with a fata=
l
> error. (the wrench in this is plain PSK, which should be restricted t=
o
> resumption within a short window; IoT people who want to use intentio=
nally
> weak security can write their own known weak spec)

yes, it would make situation better, thing is, nobody would implement t=
his and=20
nobody would deploy it (certainly not Red Hat).
People care more for availability of data than for confidentiality or=20=

integrity.

> By the way, even IE6 on XP supports DHE. Windows XP, however, appears=
 to be
> badly configured to only allow it with DSS, because missing combos fr=
om the
> cipher suite nonsense happen. If we actually have to care about IE on=
 XP,
> we could state an exception that the only non-PFS cipher suite to be
> permitted on servers for backwards compatibility is
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.

and that would prevent the server from never selecting DHE+RSA or clien=
t=20
aborting the connection when server selects DHE+RSA how exactly?

> Also add a requirement that all config provided by the admin must be
> validated to meet the TLS 1.3 requirements and auto-corrected if not,=
 with
> a warning if there's an issue.
>=20
> This doesn't have to be a mess for admins to sort out.

but it is, and for histerical reasons it will remain like this

so given choice I prefer my mess to be at least consistent between vers=
ions
=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
--nextPart55302262.phjt5pjf2m
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

iQIcBAABCgAGBQJVsSBRAAoJEJKo0bgB0vX1k1oP/0EkKeL0WVEN1I4k9hMsLZJ2
umUYpEA1Q2qecEihbueW4YfrF3RuCIy7TIYgnpx4tsV6H2PIBX6RDAA0PAY5KQIf
ti9GExjzsGTcSmWSUB4f06mLFFsnIanmjI44GvE0AHgD3NvaGrZvTptMcFOkbbD2
d7h/us9cGC0VYUGxOmNNYawEWsDoAEPoU18A8BVjKd9KFfcs8Xk9TC6xaOl7AUgK
JozeFhIYzcGFfh+WzGcr9RABkT6+uVgOz4pA92zg87qHh0Nbgc94Yra4y7pS6T3k
rKM1yhg2j6QDV8jwUWkBiWuBBn4Hbi6bNJ2HmhjQ42xbcun78J0fQvOXa1fLBGt/
MpnbLhQ8wOHG1F+szVp3Yw8Y2viwQBVR61izQ99kDPvTb8tBUdCtp3+DhlLw2ozo
ivJwOYv6/gupp55BvYKdk92FQRoe10S/ymob2g4L7vZpOswURzaG+58WCoaZyFlq
xbqizslqoAt84Z7bk4mTzIIrXn4URsOrrBy1dGZYOAYJBdjJb0u0CmFaD5neNiwP
t+NXHft6zoPYCB4f/Lpik+uy3k+2Rf/A6633+JLzNFqPd+yDnydAq8U5dZwGt/LP
ESqVajQ8ckGUq/PMvkO7vBn9hwNU259hUUVx35k2Z78iTxtw22Z1VdrSHxXSH+GN
9J01OBgFJ/0VkzY4cUwa
=1s0m
-----END PGP SIGNATURE-----

--nextPart55302262.phjt5pjf2m--