Re: [TLS] Broken browser behaviour with SCADA TLS

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 04 July 2018 08:41 UTC

Return-Path: <nmav@redhat.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 624AF130DFD for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 01:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 OSq0M5hs5_zt for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 01:41:34 -0700 (PDT)
Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) (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 04EF2130DC1 for <tls@ietf.org>; Wed, 4 Jul 2018 01:41:34 -0700 (PDT)
Received: by mail-wr0-f172.google.com with SMTP id s11-v6so4448051wra.13 for <tls@ietf.org>; Wed, 04 Jul 2018 01:41:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=qFRNYagVNgKy87fxIXT3Bvg6e4O58ATDoxx/MQWqkFU=; b=teLGk1ZJT2zHansCU6SX8/0twyNareXwP6xT1uzWgRH3MSHDqpIgQ1E9CSNgsFEZs4 er/KP8sh8vZfEMAC5OX99Jhga13yvil19gL57CjNl7bC4TREexnOoIZApd2EN7Atq2RE axt/KQJYYteZl0AWzoID7sUrrUtvjZZ9HqpibPdn3zHT6wDvkmM/m0zNGUbsAEyCX2Zq 2KhJVz9lInKAWz1QpezDjJSPwcvjS0tv0aL/QBspuFZNppSNgyWyBFUnAgjiOl4hj/VE qAYIIBNbRsu2KvjdreqdGE1VUcI/S+VB5G0NE2p+svJmOqdkh9nRxP3u6wZxU1fQ8ck7 6Erg==
X-Gm-Message-State: APt69E2m58fMogOf2R9jYdYA55HQKZxrEtpbqj/ivaEPx83QfiVhCnjx QLEng1NDM7I74vy5XWYihEnEZ5kYZIY=
X-Google-Smtp-Source: AAOMgpfaHdEroIjwo30Dw355w5I5Ujaud/eLwRqLdyg82MWWEp6rrvvMEvPOGYdfdpS+hYRAoE1a7Q==
X-Received: by 2002:adf:b815:: with SMTP id h21-v6mr894966wrf.40.1530693692502; Wed, 04 Jul 2018 01:41:32 -0700 (PDT)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id q14-v6sm6241200wmd.20.2018.07.04.01.41.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Jul 2018 01:41:31 -0700 (PDT)
Message-ID: <b8ecb2cfdac0495f188baf9df187c075e70c3a58.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Date: Wed, 04 Jul 2018 10:41:31 +0200
In-Reply-To: <20180704081519.GA20000@LK-Perkele-VII>
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>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/D-bJZZaS4IqyjRR5dfp1U3BrRxg>
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: Wed, 04 Jul 2018 08:41:37 -0000

On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote:
> > Ilari Liusvaara <ilariliusvaara@welho.com>; writes:
> > 
> > > More serious problem is servers returning too small modulus due
> > > lack of
> > > negotiation. Which was the reason why Chrome disabled DHE.
> > 
> > Why not reject the handshake if the modulus is too small, rather
> > than
> > disabling all DHE suites on the off chance that the server returns
> > a value you
> > don't like?
> 
> Chrome initially did that. It caused quite a lot of bad feedback from
> owners of various bad embedded stuff. The thread on relevant forums
> was
> quite something. Hundreds of messages blaming Google for breaking
> stuff.

We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

regards,
Nikos