IETF Logo Mail Archive

Re: [saag] Possible backdoor in RFC 5114

Watson Ladd <watsonbladd@gmail.com> Wed, 22 March 2017 18:20 UTC

Return-Path: <watsonbladd@gmail.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 40DF712986E for <saag@ietfa.amsl.com>; Wed, 22 Mar 2017 11:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Q-s88e6t2rjw for <saag@ietfa.amsl.com>; Wed, 22 Mar 2017 11:20:03 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 CA187129477 for <saag@ietf.org>; Wed, 22 Mar 2017 11:20:03 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id 21so78225740pgg.1 for <saag@ietf.org>; Wed, 22 Mar 2017 11:20:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BqrOL+NUUuG4xKPfwvC0JZrXFqSRgfQtWc4B65u89Jo=; b=nCSix0XepgeIB4hISuTJyIbGTUEASjigwz4tRX0hgYcxef/Bl+Nq24RbWjj0Q42dE6 JjaIAQDOaWNSwS/b34xklzHw+ULXoXPMZrReCwk3gSH4wbc47dg4mP64YReo4I8JLPXk uP8574JXeIGMjPHgl4QaaJDnV40Gn1EsB0zlIMzPsE6ZrNoYxilBTcSMTZIKPePclhsY GfW4oAFtIxIZwv16fEdjZs72CI0bhBe3Gk6qqVMpFUV8AtEWPBzT/KRJxD3T+8mwTcKx L8YIP/0nvAeiS+6mSFGT5Lpqwy8YSwd05865R380EXm5LS7WAnR8ZX7tn76stG1yLUve 68NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BqrOL+NUUuG4xKPfwvC0JZrXFqSRgfQtWc4B65u89Jo=; b=Kzu61/G2n68w76qW3VD7fjyjfZgEUD5+ZywB7qeOS1fJ1a3izLl42305N28UtnJQap Y74AMUKE258uXcVtPD7Aq3YUPTlpoYbIEKdWkfbpeAoVfslU3UVwbgK7DV2tYbb1XTmg RulWocRb8DhOsEEcjpxfmKmNXKSGv8EkuGAMAc/gR/EGW5tjeK3jShWjuKIB78AFj/9n GOyIXmX/xYQLdmaic7hPh8PV8wkerxl7B+KAF4q9boKRX4pik2JLXGlONJkVAsOx0vvx YqLGILh81dbMwa0u3Nzv8s9iIboMrQc0QD0oczCWkwAMq20LUeBvNh4YAuNg7BQWje1r dM1g==
X-Gm-Message-State: AFeK/H0teDZPwu0nHD+/ApmhqNCXQXkH/7UuCA9XzieFMmaG/3XXroNiUxb1Br0uNvvI7ZdRNvfP1fXTcTeMWw==
X-Received: by 10.98.13.16 with SMTP id v16mr47756764pfi.38.1490206803394; Wed, 22 Mar 2017 11:20:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.169.165 with HTTP; Wed, 22 Mar 2017 11:20:02 -0700 (PDT)
Received: by 10.100.169.165 with HTTP; Wed, 22 Mar 2017 11:20:02 -0700 (PDT)
In-Reply-To: <CACsn0cnSiY7y80U05KsPtmZfjQ1sAuvQ=J3hfPpoSMSs7WaaMA@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> <CADF337F-88BC-4B9E-B05F-94F146CB068B@gmail.com> <CABrd9SRXO684K04jk002VoLgTnbE0AJNG2kH-h7KCMn8Hi9VvQ@mail.gmail.com> <CACsn0c=-+ywD4Xp=SrRm_8_q71kGsb_CML5-2D+WHi0XC8AXoQ@mail.gmail.com> <CACsn0cnSiY7y80U05KsPtmZfjQ1sAuvQ=J3hfPpoSMSs7WaaMA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 22 Mar 2017 11:20:02 -0700
Message-ID: <CACsn0cnn2L4SMq4uA34QRfym=Hmr9VRreBjZzB8Sj4-dfsoW5A@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, saag@ietf.org, Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="001a11467c72288578054b55cf44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/8ppztNqI_uHg5984StOZ8gv9SPk>
Subject: Re: [saag] Possible backdoor in RFC 5114
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 22 Mar 2017 18:20:06 -0000

On Mar 22, 2017 8:15 AM, "Ben Laurie" <benl@google.com> wrote:



On 7 October 2016 at 16:56, Yoav Nir <ynir.ietf@gmail.com> wrote:

>
> > On 7 Oct 2016, at 16:59, Tero Kivinen <kivinen@iki.fi> wrote:
> >
> > Stephen Farrell writes:
> >>
> >> So I'm not seeing anyone so far argue to not
> >> deprecate these somehow.
> >>
> >> We could just make 5114 historic as Yoav suggests,
> >> or, if someone writes an I-D to explain why, we
> >> could obsolete 5114. (Such an I-D would presumably
> >> also say something about codepoints that point at
> >> 5114 from other registries.)
> >>
> >> Assuming nobody shows up saying these are in
> >> fact in widespread use I'd be supportive of us
> >> getting rid of cruft.
> >
> > I think the NIST ECP groups are quite widely supportd, and used.
> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) and
> > 3 MODP groups.
> >
> > In IPsec, ECP groups are widely used, those MODP groups with subgroup
> > are not. On the other hand I think only those 192, 256 and 521 bit
> > groups are really used, and those are defined also in RFC5903 (which
> > obsoleted original 4753 which had serious bug in it).
>
>
> First, I think you meant 256, 384 and 521 bit, not the 192.
>
> Second, 5114 did not fix the bug in 4753. It just referenced 4753 for
> formatting. You know this better than I do, but I don’t think the IANA
> registry ever referenced 5114 for these ECP groups.
>
> So for the three useful groups in 5114 you didn’t need it (as 4753)
> already existed, and you don’t need it now, as 5903 exists. I don’t see
> anything standing in the way of moving to historic or obsoleting it.
>

Possibly I missed something here: why should we be any happier about 5903
than we are about 5114?


Can you prepare a backdoored elliptic curve that passes all acceptence
critera?

The reason not to use 5114 is that one can construct moduli with hidden
SNFS structure.



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

v2.23.0 | Report a Bug | By Email