Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Ryan Hamilton <rch@google.com> Sat, 27 August 2016 14:28 UTC

Return-Path: <rch@google.com>
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Sat, 27 Aug 2016 07:28:34 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id o80so29920320wme.1 for <tls@ietf.org>; 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> <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> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz>
From: Ryan Hamilton <rch@google.com>
Date: Sat, 27 Aug 2016 07:28:31 -0700
Message-ID: <CAJ_4DfRzXbEK2m0B3KF=8svGSz_Dc8fiPgYacv2Z6hzmOEgKQg@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=001a1145a97c0caeb6053b0e7294
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WY89yyRAu1nXXU0MLN6geCvlWM8>
Cc: Geoffrey Keating <geoffk@geoffk.org>, "tls@ietf.org" <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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Aug 2016 14:28:36 -0000

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.  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 release.
>
> 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 always
> 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?
>

​Alternatively, 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.​


> 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
>