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
- [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Jeffrey Walton
- Re: [saag] Possible backdoor in RFC 5114 Yoav Nir
- Re: [saag] Possible backdoor in RFC 5114 Jeffrey Walton
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Viktor Dukhovni
- Re: [saag] Possible backdoor in RFC 5114 Peter Gutmann
- Re: [saag] Possible backdoor in RFC 5114 Jeremy Harris
- Re: [saag] Possible backdoor in RFC 5114 Stephen Farrell
- Re: [saag] Possible backdoor in RFC 5114 Tero Kivinen
- Re: [saag] Possible backdoor in RFC 5114 Yoav Nir
- Re: [saag] Possible backdoor in RFC 5114 Panos Kampanakis (pkampana)
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Dang, Quynh (Fed)
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Dang, Quynh (Fed)
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Tero Kivinen
- Re: [saag] Possible backdoor in RFC 5114 Tero Kivinen
- Re: [saag] Possible backdoor in RFC 5114 Mark D. Baushke
- Re: [saag] Possible backdoor in RFC 5114 Peter Gutmann
- Re: [saag] Possible backdoor in RFC 5114 Antonio Sanso
- Re: [saag] Possible backdoor in RFC 5114 Tony Finch
- Re: [saag] Possible backdoor in RFC 5114 Yoav Nir
- Re: [saag] Possible backdoor in RFC 5114 Antonio Sanso
- Re: [saag] Possible backdoor in RFC 5114 Ben Laurie
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Ben Laurie
- Re: [saag] Possible backdoor in RFC 5114 Yoav Nir
- Re: [saag] Possible backdoor in RFC 5114 Ben Laurie
- Re: [saag] Possible backdoor in RFC 5114 Watson Ladd
- Re: [saag] Possible backdoor in RFC 5114 Ben Laurie