From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: David Benjamin <davidben@chromium.org>, Geoffrey Keating
 <geoffk@geoffk.org>
Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman
 Ephemeral Parameters for Transport Layer Security (TLS)
Thread-Index: AQHR+kiDZXbZlYKpgUOnaUdD5zLR56BP1VcAgA0Cxf4=
Date: Sat, 27 Aug 2016 13:27:15 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz>
 <20160816145548.GQ4670@mournblade.imrryr.org>
 <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz>
 <CADMpkc+vbkWz_TQ2Ch5JfaVRPse4qeXPPitsBV=d2yDtSx4eLA@mail.gmail.com>
 <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz>
 <m260qwppxa.fsf@localhost.localdomain>,
 <CAF8qwaB-p1X6vcKZ7=GfPe_hWxOB+g4T2mKaugpbYAKNJngJ7g@mail.gmail.com>
In-Reply-To: <CAF8qwaB-p1X6vcKZ7=GfPe_hWxOB+g4T2mKaugpbYAKNJngJ7g@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2LXIkGT6BkoWG1dNMmLQQUdhJE0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman
 Ephemeral Parameters for Transport Layer Security (TLS)
Precedence: list

David Benjamin <davidben@chromium.org> writes:=0A=
=0A=
>TLS 1.3 will resolve this with the new cipher suite negotiation, but I agr=
ee=0A=
>this makes the specification basically undeployable with TLS 1.2. This iss=
ue=0A=
>also got brought up here:=0A=
>https://www.ietf.org/mail-archive/web/tls/current/msg18697.html=0A=
=0A=
Hmm, good point.  So reading between the lines of the various comments on t=
his=0A=
issue, the feeling seems to be "ignore this RFC".  That more or less answer=
s=0A=
my question, I'll leave it out of TLS-LTS apart from mentioning it as anoth=
er=0A=
source of DH groups.=0A=
=0A=
>Barring unforeseen problems, Chrome will also lose DH in the next release.=
=0A=
=0A=
Which will be yet another headache for people working with SCADA devices, w=
ho=0A=
are seeing themselves locked out more and more from being able to admin the=
ir=0A=
systems when browser vendors arbitrarily decide to deprecate long-establish=
ed=0A=
mechanisms.  I know of operators who are running IE 6 in XP VMs because tha=
t's=0A=
the only thing that'll still talk to some devices they use (OK, old version=
s=0A=
of FF and Chrome will do it too if you can find them, but then they always=
=0A=
want to update themselves to less old versions that stop working again). =
=0A=
=0A=
Couldn't Chrome include an optional legacy mode that just works with existi=
ng=0A=
systems, perhaps triggered by access to a device at an RFC 1918 address?=0A=
There really is, in some cases, nothing available any more that will talk t=
o=0A=
entire families of SCADA devices because browsers assume the only thing tha=
t=0A=
matters is the public WWW and won't accommodate anything that isn't.=0A=
=0A=
(At some point someone's going to figure out they can make a lot of money b=
y=0A=
taking Firefox 3.0, rebranding it, and selling it as an embedded device=0A=
management solution, because it'll talk to all the things that current=0A=
browsers won't any more).=0A=
=0A=
Peter.=