Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors

Damien Miller <djm@mindrot.org> Fri, 30 September 2016 05:41 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08212B062 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 29 Sep 2016 22:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 7-r6pkHTLpMS for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 29 Sep 2016 22:41:42 -0700 (PDT)
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C752812B04B for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Thu, 29 Sep 2016 22:41:42 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 8C10C85EF1; Fri, 30 Sep 2016 05:41:41 +0000 (UTC)
Delivered-To: ietf-ssh@NetBSD.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BD6F985EEA for <ietf-ssh@NetBSD.org>; Fri, 30 Sep 2016 05:41:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id nlbadwRGKyUK for <ietf-ssh@netbsd.org>; Fri, 30 Sep 2016 05:41:39 +0000 (UTC)
Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id AEFE384CED for <ietf-ssh@NetBSD.org>; Fri, 30 Sep 2016 05:41:36 +0000 (UTC)
Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8U5fSta039362; Fri, 30 Sep 2016 15:41:28 +1000
Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8U5fS2S055201 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Sep 2016 15:41:28 +1000
Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u8U5fRT6013866 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Fri, 30 Sep 2016 15:41:27 +1000 (AEST)
Received: by natsu.mindrot.org (Postfix, from userid 1000) id 4247CA4F2E; Fri, 30 Sep 2016 15:41:27 +1000 (AEST)
Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 390B2A4F07; Fri, 30 Sep 2016 15:41:27 +1000 (AEST)
Date: Fri, 30 Sep 2016 15:41:27 +1000
From: Damien Miller <djm@mindrot.org>
To: "Mark D. Baushke" <mdb@juniper.net>
cc: ietf-ssh@NetBSD.org, curdle@ietf.org, frg@irtf.org
Subject: Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors
In-Reply-To: <91352.1475176974@eng-mail01.juniper.net>
Message-ID: <alpine.BSO.2.20.1609301533050.22485@natsu.mindrot.org>
References: <35937.1475160447@eng-mail01.juniper.net> <alpine.BSO.2.20.1609300328040.29933@natsu.mindrot.org> <91352.1475176974@eng-mail01.juniper.net>
User-Agent: Alpine 2.20 (BSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub
X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17
X-UQ-FilterTime: 1475214089
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

On Thu, 29 Sep 2016, Mark D. Baushke wrote:

> > NOBUS backdoors aren't the only concern; another motivation was
> > logjam-style precomputation attacks.
>
> Yes, the creation of a new set of DH parameters allows us to avoid
> logjam precomputation attacks against a well known set of DH groups.
>
> That said, with NOBUS, how is an SSH client able to identify improper
> ephemeral DH parameters that have been intesionally weakened?

I think there's little point - a peer that wants to leak has myraid
ways to do so. E.g. it could leak keys via nonces, random padding, DH
public values, optional packet padding, etc.

Leaking by backdooring DH groups is possibly the worst way to do it -
the only reason they can't be properly tested by a client is that its
too expensive to do so at connection time. That doesn't mean that it
couldn't be done post-hoc or even passively, since the values are sent
in the clear (at least for the inital KEX).

That's not the case with the other leak paths. E.g. leaking a PRNG
seed by encrypting it with a public key and putting it in the KEXINIT
nonce is undetectable on the wire and NOBUS as far as you trust your PK
crypto.

-d