MIME-Version: 1.0
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>
In-Reply-To: <m260qwppxa.fsf@localhost.localdomain>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 19 Aug 2016 18:43:12 +0000
Message-ID: <CAF8qwaB-p1X6vcKZ7=GfPe_hWxOB+g4T2mKaugpbYAKNJngJ7g@mail.gmail.com>
To: Geoffrey Keating <geoffk@geoffk.org>,
 Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=001a11440f7eb42cac053a7112f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA>
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

--001a11440f7eb42cac053a7112f4
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating <geoffk@geoffk.org> wrote:

> Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
>
> > The problem is that 7919 doesn't say "I want to do DHE, if possible
> > with these parameters", it says "I will only accept DHE if you use
> > these parameters, otherwise you cannot use DHE but must drop back to
> > RSA".  Talk about cutting off your nose to spite your face, you'd
> > have to have rocks in your head to want to break your implementation
> > like that.
>
> Actually, my problem with the RFC is the reverse.  If you have an
> implementation which won't accept certain DH groups, and those are
> extremely common in legacy software (1024-bit, for example), there's
> no way to stop those legacy implementations ignoring the extension and
> choosing DH, which you will then have to reject, doubling connection
> establishment time.
>
> So Apple's client still has DH off.
>
> However I don't see a helpful solution to this; the obvious thing is
> to have a new ciphersuite, but it's hard to see how that would be
> worth the effort if it requires new implementations and ECDHE is
> already standardised and already implemented in many places.
>

TLS 1.3 will resolve this with the new cipher suite negotiation, but I
agree this makes the specification basically undeployable with TLS 1.2.
This issue also got brought up here:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

Barring unforeseen problems, Chrome will also lose DH in the next release.
We certainly could not deploy this without the separate cipher suite
numbers. But I can't imagine Chrome deploying it with the separate cipher
suite numbers either for the same reason as Geoffrey. It does not seem
worth bothering when ECDHE is already widely deployed.

David

--001a11440f7eb42cac053a7112f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 19=
, 2016 at 2:35 PM Geoffrey Keating &lt;<a href=3D"mailto:geoffk@geoffk.org"=
 target=3D"_blank">geoffk@geoffk.org</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Peter Gutmann &lt;<a href=3D"mailto:pgut001@cs.auckland.ac=
.nz" target=3D"_blank">pgut001@cs.auckland.ac.nz</a>&gt; writes:<br>
<br>
&gt; The problem is that 7919 doesn&#39;t say &quot;I want to do DHE, if po=
ssible<br>
&gt; with these parameters&quot;, it says &quot;I will only accept DHE if y=
ou use<br>
&gt; these parameters, otherwise you cannot use DHE but must drop back to<b=
r>
&gt; RSA&quot;.=C2=A0 Talk about cutting off your nose to spite your face, =
you&#39;d<br>
&gt; have to have rocks in your head to want to break your implementation<b=
r>
&gt; like that.<br>
<br>
Actually, my problem with the RFC is the reverse.=C2=A0 If you have an<br>
implementation which won&#39;t accept certain DH groups, and those are<br>
extremely common in legacy software (1024-bit, for example), there&#39;s<br=
>
no way to stop those legacy implementations ignoring the extension and<br>
choosing DH, which you will then have to reject, doubling connection<br>
establishment time.<br>
<br>
So Apple&#39;s client still has DH off.<br>
<br>
However I don&#39;t see a helpful solution to this; the obvious thing is<br=
>
to have a new ciphersuite, but it&#39;s hard to see how that would be<br>
worth the effort if it requires new implementations and ECDHE is<br>
already standardised and already implemented in many places.<br></blockquot=
e><div><br></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>TLS=
 1.3 will resolve this with the new cipher suite negotiation, but I agree t=
his makes the specification basically undeployable with TLS 1.2. This issue=
 also got brought up here:</div><div><a href=3D"https://www.ietf.org/mail-a=
rchive/web/tls/current/msg18697.html">https://www.ietf.org/mail-archive/web=
/tls/current/msg18697.html</a></div><div><br></div><div>Barring unforeseen =
problems, Chrome will also lose DH in the next release. We certainly could =
not deploy this without the separate cipher suite numbers. But I can&#39;t =
imagine Chrome deploying it with the separate cipher suite numbers either f=
or the same reason as Geoffrey. It does not seem worth bothering when ECDHE=
 is already widely deployed.</div></div></div><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div><br></div><div>David=C2=A0</div></div></div></div>

--001a11440f7eb42cac053a7112f4--