Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6812D5A2 for ; Sat, 27 Aug 2016 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwg4cWd4UzzJ for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4883112D590 for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so29920320wme.1 for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KJ5sg8qjbK6sd8XRcApluEa01QuPhBHPHGeUctwskl0=; b=LF/AJGPI56l9zDnbuRSwZzKIBCNN0bhlxu/5qPjLrX7R4EE5Dz+mbS3J7NCDVNeCAK Hu8mYtCdFgqk0llPXSW2Ly7fSVg9ERjZMldoCW+IB/8SX9CQw36WoQmCnG5srV0l7mxY 7PSJ1aJ8v24U6KXvnMpJGHvPT5oXb59IzlKPQtgBAKDV4GTERcj42/YAAXnzDvCjJwa3 Ldrey8ifTFmSpASm47vGVAhLNzNAW3ghX+E4WKvcO+QoVfgtqkZ4qVHtloZcGeFr6t/R f84rwpnjq/NGwO154NdZjPL5rmET5GXlP0nieDoG/MEcYV6hZ3vg9v9reB+2llCRcUKg 5iZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KJ5sg8qjbK6sd8XRcApluEa01QuPhBHPHGeUctwskl0=; b=hj2U8edJqGE2KY3sLec9bBw4TRXSGBokk/MCw/PouuuoNaH7SEiZBx6tWgPfmgm+xM l0DKEUQLUZUpkoecPfUq0ujTKidZ/B/Njdo9XisQinhQBmJCx5GL18+wsban7lGEvUya zI6zt6ZLYdiWw7DxRr0vbLUhMsYc/Bd46yrYVQ2ofvIra5J6+64XJ6aHqqgpyRmiBbCU 3FYcNaNnYLoV7Cw4td7XgauN+Gkgcsu4Yckbcx/J4y8ulnktxH41Oaqu/fqR2QJSr2zi jV2cKSoVZeawUEbMJLbAItF2bNpu3e3oA/+V/TLdwQ56zyVlj175XEmjaXB5rTRbHwhi AaSA== X-Gm-Message-State: AE9vXwMCaf9zAcbJxSxy6DpKVXKMrn/Ux1Q37wqFIVOOSppJtyzCrh/vOiG8kEHZcfeaBlSaoKrZ6UzDkvRIaw// X-Received: by 10.28.145.137 with SMTP id t131mr3475218wmd.110.1472308112539; Sat, 27 Aug 2016 07:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.68 with HTTP; Sat, 27 Aug 2016 07:28:31 -0700 (PDT) In-Reply-To: <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> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> From: Ryan Hamilton Date: Sat, 27 Aug 2016 07:28:31 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a1145a97c0caeb6053b0e7294 Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 14:28:36 -0000 --001a1145a97c0caeb6053b0e7294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2016 at 6:27 AM, Peter Gutmann wrote: > David Benjamin writes: > > >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 > > Hmm, good point. So reading between the lines of the various comments on > this > issue, the feeling seems to be "ignore this RFC". That more or less > answers > my question, I'll leave it out of TLS-LTS apart from mentioning it as > another > source of DH groups. > > >Barring unforeseen problems, Chrome will also lose DH in the next releas= e. > > Which will be yet another headache for people working with SCADA devices, > who > are seeing themselves locked out more and more from being able to admin > their > systems when browser vendors arbitrarily decide to deprecate > long-established > mechanisms. I know of operators who are running IE 6 in XP VMs because > that's > the only thing that'll still talk to some devices they use (OK, old > versions > of FF and Chrome will do it too if you can find them, but then they alway= s > want to update themselves to less old versions that stop working again). > > Couldn't Chrome include an optional legacy mode that just works with > existing > systems, perhaps triggered by access to a device at an RFC 1918 address? > =E2=80=8BAlternatively, someone could write a "Legacy TLS" to "Current TLS"= proxy, which could run on the client's computer to sit in front of these legacy devices. This would allow browsers to continue adding new security features to protect users, while still allowing access to legacy systems.=E2=80=8B > There really is, in some cases, nothing available any more that will talk > to > entire families of SCADA devices because browsers assume the only thing > that > matters is the public WWW and won't accommodate anything that isn't. > > (At some point someone's going to figure out they can make a lot of money > by > taking Firefox 3.0, rebranding it, and selling it as an embedded device > management solution, because it'll talk to all the things that current > browsers won't any more). > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1145a97c0caeb6053b0e7294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 27, 2016 at 6:27 AM, Peter Gutmann = <pgut001@cs.auckland.ac.nz> wrote:
David Benjamin <davidben@chromium.org> writes:
>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

Hmm, good point.=C2=A0 So reading between the lines of the various c= omments on this
issue, the feeling seems to be "ignore this RFC".=C2=A0 That more= or less answers
my question, I'll leave it out of TLS-LTS apart from mentioning it as a= nother
source of DH groups.

>Barring unforeseen problems, Chrome will also lose DH in the next relea= se.

Which will be yet another headache for people working with SCADA dev= ices, who
are seeing themselves locked out more and more from being able to admin the= ir
systems when browser vendors arbitrarily decide to deprecate long-establish= ed
mechanisms.=C2=A0 I know of operators who are running IE 6 in XP VMs becaus= e that's
the only thing that'll still talk to some devices they use (OK, old ver= sions
of FF and Chrome will do it too if you can find them, but then they always<= br> want to update themselves to less old versions that stop working again).
Couldn't Chrome include an optional legacy mode that just works with ex= isting
systems, perhaps triggered by access to a device at an RFC 1918 address?

=E2=80=8BAlternatively, someo= ne could write a "Legacy TLS" to "Current TLS" proxy, w= hich could run on the client's computer to sit in front of these legacy= devices. This would allow browsers to continue adding new security feature= s to protect users, while still allowing access to legacy systems.=E2=80=8B=
=C2=A0
There really is, in some cases, nothing available any more that will talk t= o
entire families of SCADA devices because browsers assume the only thing tha= t
matters is the public WWW and won't accommodate anything that isn't= .

(At some point someone's going to figure out they can make a lot of mon= ey by
taking Firefox 3.0, rebranding it, and selling it as an embedded device
management solution, because it'll talk to all the things that current<= br> browsers won't any more).

Peter.
_____________________= __________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo= /tls

--001a1145a97c0caeb6053b0e7294--