Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

Stephen Kent <kent@bbn.com> Tue, 18 October 2016 14:47 UTC

Return-Path: <kent@bbn.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761941294A7; Tue, 18 Oct 2016 07:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9r39hOuNwoZu; Tue, 18 Oct 2016 07:47:05 -0700 (PDT)
Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (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 E029C12948C; Tue, 18 Oct 2016 07:47:04 -0700 (PDT)
Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u9IEl0pY024719 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 14:47:02 GMT
Received: from smtp.bbn.com ([128.33.1.81]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u9IEl0Ie002381 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Tue, 18 Oct 2016 14:47:00 GMT
Received: from ssh.bbn.com ([192.1.122.15]:43572 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1bwVfQ-000CJu-Az; Tue, 18 Oct 2016 10:47:00 -0400
From: Stephen Kent <kent@bbn.com>
To: Paul Wouters <paul@nohats.ca>, Yoav Nir <ynir.ietf@gmail.com>
References: <alpine.LRH.2.20.1610091711050.8864@bofh.nohats.ca> <D42AB86C.538C3%john.mattsson@ericsson.com> <CADZyTknqvF=zxW2thuN7mf_St2UmnWZzd8dVb5dWzDJ5=8tz5w@mail.gmail.com> <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <alpine.LRH.2.20.1610171206070.827@bofh.nohats.ca>
Message-ID: <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com>
Date: Tue, 18 Oct 2016 10:47:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.20.1610171206070.827@bofh.nohats.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CC: saag@ietf.org, ipsec@ietf.org, ynir.ietf@gmail.com, paul@nohats.ca
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-18_07:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/is67FiG6h1ApM6niKU6o-p8gkCo>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 14:47:06 -0000

Paul,

It's  been over 8 years since this RFC was published, and I have not 
looked at it since then. My recollection is that we wrote 5114 because 
an IPsec developer approached me and said that he wanted to support 
these groups in a product. He said that he wanted test vectors for the 
groups, consistent with what we have done for many other algs. I 
persuaded Matt to generate the RFC because it was a relatively easy task 
a good way for Matt to get acquainted with the RFC process.

As to your question, I have no info about how the NIST DH values were 
generated. However, I do agree with Yoav and Tero that it seems unduly 
prejudicial to declare these to be a MUST NOT. The fact that one can 
generate trap-doored DH values that cannot be detected is not the same 
as having proof that a given set of values have been generated in that 
fashion. Moreover, if one interprets a MUST NOT in this context to mean 
that an implementation supporting any of these groups is non-compliant, 
then that unfairly penalizes existing implementations, as Tero noted. 
Moreover, if the concern raised by the paper (which I have read) is with 
MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits 
that criteria (section 2.1).

I have not tracked the status of these NIST groups re evaluation 
criteria like FIPS 140-2. If these groups are approved for use in 
products evaluated under that FIPS (I don't know if they are), 
deprecating them creates a possible conundrum for vendors who want to 
comply with RFCs and with FIPS evaluation criteria. Thus I suggest a 
less dramatic response than declaring all of the groups in 5114 to be 
MUST NOT.

I'm not a vendor of any crypto products (these days), and I've never 
been a crypto mathematician. So my views are based only on what I recall 
about the creation of 5114 and about IETF crytpo standards practices in 
general.

Steve