Re: [saag] Possible backdoor in RFC 5114

Tero Kivinen <kivinen@iki.fi> Mon, 10 October 2016 12:22 UTC

Return-Path: <kivinen@iki.fi>
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 9C0C2129632 for <saag@ietfa.amsl.com>; Mon, 10 Oct 2016 05:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 V9IlITpl4H3m for <saag@ietfa.amsl.com>; Mon, 10 Oct 2016 05:22:02 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 2466B129631 for <saag@ietf.org>; Mon, 10 Oct 2016 05:22:01 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9ACLrAE020860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Oct 2016 15:21:53 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9ACLrg3010917; Mon, 10 Oct 2016 15:21:53 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22523.34784.950203.387050@fireball.acr.fi>
Date: Mon, 10 Oct 2016 15:21:52 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Watson Ladd <watsonbladd@gmail.com>
In-Reply-To: <CACsn0cnag=PYkETG9gNUim6cd9k1NK8UAhJa7BU7Vtb3H54YjA@mail.gmail.com>
References: <CACsn0ck9u3ct3wD7xWXtDZ89Q1R6OKTQFMYuZ56_vY2ys+1=YQ@mail.gmail.com> <bfa71c30-3ccc-1538-c682-33e14c910e21@cs.tcd.ie> <22519.43588.421250.807948@fireball.acr.fi> <75a7525e2d954da192e056ff32c632ca@XCH-ALN-010.cisco.com> <CACsn0cnag=PYkETG9gNUim6cd9k1NK8UAhJa7BU7Vtb3H54YjA@mail.gmail.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 21 min
X-Total-Time: 24 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/czHZnBfjGSwAtpETpev-qmORRbI>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] Possible backdoor in RFC 5114
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: Mon, 10 Oct 2016 12:22:03 -0000

Watson Ladd writes:
> The IANA registry cites 5903, not 5114, for these groups, so
> historifying 5114 would have no effect. I'm not entirely sure what
> historifying does to registries in terms of marking DO NOT USE: maybe
> a separate draft is required.

Moving document to historic does not change anything in the IANA
registries. To make changes to the IANA registries, you need separate
document, IESG action, or designated expert agreeing on change,
depending on the registry. And the IANA registries do not give
recommendations whether algorithm is good to use be used or not, and
adding such thing to IANA registries would be bad idea.

The IANA IKEv2 registry still includes algorithms like 768-bit MODP
Group, and single DES. It does not mean that you are fine using those. 

IANA registries are not saying that you should or should not implement
certiain algorithms, they provide mappings between numbers,
identifiers and specifications. 

> I am not a process expert. Furthermore in at least some cases the
> IKE registries get used by people hunting for DH parameters. Do we
> need a draft here? What should that look like?

IKE registries are supposed to be used for protocols related to IKE.
If other people use them for other reasons, there is nothing we can do
for that.

> It's not SHOULD NOT. It's "using these groups even outside of IKE will
> result in pwnage". Do you agree we need a stronger warning about known
> bad cryptographic constructions? What do you think that should look
> like?

In IPsec we do publish warnings and recommendations in the separate
documents (rfc4307bis and rfc7321bis, work in progress). And
rfc4307bis do contain SHOULD NOT for those groups, and gives reason
for that.

If you think wider warning is really need, you can write document
saying rfc5114-die-die-die, and get that published. That will not
still remove RFC5114, at best it could be moved to historic if other
people agree with you, but that still does not affect the fact that
people still might use that rfc5114 as reference.

Regardless what we do we cannot protect people from making mistakes.
If they want to make weak crypto, there is nothing we can do. I am
pretty sure that even if they use RFC5114 groups, those groups are not
the weakest point in their protocol. 

Btw, can you point me the reference which says that those groups are
really backdoored? What I have seen is people saying that as those
might be backdoored, they must been backdoored, and I myself do not
find that very convincing argument. On the other hand as there is no
seed etc published on how those groups are generated, they might be
backdoored, and I think that is good reason for SHOULD NOT for IPsec.
-- 
kivinen@iki.fi