IETF Logo Mail Archive

Re: [TLS] Broken browser behaviour with SCADA TLS

Adam Langley <agl@imperialviolet.org> Thu, 05 July 2018 13:49 UTC

Return-Path: <alangley@gmail.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 CABC4130E2A for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 06:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 nvR9b_tYm0gQ for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 06:49:53 -0700 (PDT)
Received: from mail-pl0-f53.google.com (mail-pl0-f53.google.com [209.85.160.53]) (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 7C3ED130E29 for <tls@ietf.org>; Thu, 5 Jul 2018 06:49:53 -0700 (PDT)
Received: by mail-pl0-f53.google.com with SMTP id 30-v6so1290175pld.13 for <tls@ietf.org>; Thu, 05 Jul 2018 06:49:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QGKRZXD+j9Ug9aVCQhh9/Ew/4Db05SK5TW3I3tHaCsI=; b=OHI75r83Mk8iABZdTl3HFUNLJPPAhZBGPAmuBa2OmlrnaFanN48CQsbgA6CrqLFhlP NEyY8aRDaGIe2eWT6ffyw8FLPxpkrQftH11ZwpH6bGbiP9I9jJ7QCdr3u5N+TSgCKz5S 2q34C1IupxLptYUREFpSeFm0Cyg6NCmughT9uM5geI6BW7i58HXOogKD96K/Jx3RQ8Sx 11CG8lteCRv9whJu1qO58yAkeN78p0WkClTujEU/cdt5bXlcodyL+Ghggjd1xve8ee1T meMausVaFFgOORmIhOKK5wSkFCOC5Wj+X7nNU8x/5ROq1ggVUdwzU2hsbAiFtWFTGGR1 mJdw==
X-Gm-Message-State: APt69E3dOaAq5mHJ5jbumhy01HLV58JMRNBTwUZG1CjMjR+Pwp/xrGUc HXdxzQ9Pd3Z7IGFHcy3Zf2tp8TdqMONMqwUEfTo=
X-Google-Smtp-Source: AAOMgpdg3FiO/9fowvr9DBAj10IKxL4XGSOZ/Tu2icMT9FsADYTSHBV6JhOST/zA4e0rpeB/WyTh6cPi4lCB7XPLTz4=
X-Received: by 2002:a17:902:7581:: with SMTP id j1-v6mr6311311pll.218.1530798592913; Thu, 05 Jul 2018 06:49:52 -0700 (PDT)
MIME-Version: 1.0
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530756106390.98539@cs.auckland.ac.nz> <20180705064455.GA7996@LK-Perkele-VII> <1530792281962.34902@cs.auckland.ac.nz>
In-Reply-To: <1530792281962.34902@cs.auckland.ac.nz>
From: Adam Langley <agl@imperialviolet.org>
Date: Thu, 05 Jul 2018 06:49:37 -0700
Message-ID: <CAMfhd9XYXpmmVmPKFcB963G3PesHyAqumWLrc-yGfHMo=fCcyQ@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EhGJLqkJFMexFGd_xF7ddeIsWhA>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 13:49:55 -0000

On Thu, Jul 5, 2018 at 5:05 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> The crazy thing is that although Chrome rejects a connection to a PFS,
> relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly
> happy connecting to a far less safe (both in terms of factorability and use of
> pure RSA) 1024-bit RSA server.

A 2048-bit minimum for RSA acts via the CA/Browser Forum rules: it
should not be possible to get a publicly-trusted certificate with a <
2048-bit key and, if it happens, we have proportionate measures to
address it.

However, it's not practically possible to fix the small DHE defaults
across all servers and, even if we could, that would have broken many
Java clients. Thus the DHE ecosystem was poisoned and, given that DHE
has been exceeded by ECDHE, it wasn't worth trying to save it.

We have not (at least so far) acted to enforce a 2048-bit RSA minimum
in the client as the CA/BF rules suffice for the vast, vast majority
of users.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

v2.23.0 | Report a Bug | By Email