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

Watson Ladd <watsonbladd@gmail.com> Tue, 18 October 2016 14:31 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 291AA12965B; Tue, 18 Oct 2016 07:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ULpn3J0G1XnY; Tue, 18 Oct 2016 07:31:28 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 BF4D5129445; Tue, 18 Oct 2016 07:31:27 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id f128so282609461qkb.1; Tue, 18 Oct 2016 07:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oKH8Nl/9xEsHjf+N1I04x1a2XYvJnHG5MAWmfBXHDlg=; b=ql6p8J3fFQFDubYr7cG5AZ66waMCUF/TaUB86F5VXYh9cNTmOKawqB+7qP4h1iz1os j/cIW9Kfl6Iceuktg4XZ634PlOWF0DeTYJ9iL4UHvM8JX/gxoLUyw9GoY52EPyVidaH2 fikMaRCTWci0bBFtBbysCE5D/mGXG8fuR5zxpbmoSWj4mH+gCii8v0h+erlAGeG4Xins 7Pqm7uCDqRG9WUgbZ9GCLHynW4VnQq+iSAToLiXuvVG9p10mdlSDaKZ9oHj9w3iXkkPs re/vc2zRMoF1CZUfeDCsBAz95wwAsI1qMyh7aMSECdzYpSeXzrL/4nFR5fwy6EGVOBBF 2RoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oKH8Nl/9xEsHjf+N1I04x1a2XYvJnHG5MAWmfBXHDlg=; b=CVyg57aeEN7b3+apClh2JqaxHYkjYpnjApOlxoeiafOk7IA3PE6zZ5vvzCK3x6gO7i gIbzkJp8nVoT6h6kfaT2wbJM5VOo79kLnmWrZ5CMj4yI2sBfLou0ALeJmPPZvCF4BK02 AeK1AxvwFafbyN8paVxgsSfbF4LyGD3fmx1fginZ0c/xAq9OkR63I8HCDIuBa9946Ppi nHnYmbOCdlWQf0Vi3oYl4m5CWs5BiDObs8PLZhO26GNW2hfs7nNXgveFnQRf0tlgNJ0E TLFNpiJkWOhLVqt3v6DYzPF+eUfRwoufZ3rjyTA1VjeyfiD+B39aY2JdbKoy1TOZJjKC xd0Q==
X-Gm-Message-State: AA6/9Rn5LSHazeYdBZqFUJQO3TC4kolPTVBgQxwMBerW6dQaW5ErOpjwBxJaz5GxCKSCAB7SQR9B97HQ2tRJRw==
X-Received: by 10.55.96.7 with SMTP id u7mr904150qkb.189.1476801071198; Tue, 18 Oct 2016 07:31:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.171.87 with HTTP; Tue, 18 Oct 2016 07:31:10 -0700 (PDT)
In-Reply-To: <22533.64120.595277.953942@fireball.acr.fi>
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> <22533.64120.595277.953942@fireball.acr.fi>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 18 Oct 2016 07:31:10 -0700
Message-ID: <CACsn0cn74b6Spu_Uc=75XLkn5VNMTB1oeXGKv=cJMUpFcL4uzw@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/UQhJTjBIw5-io1DRUP65EeaaNS8>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Paul Wouters <paul@nohats.ca>, 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:31:30 -0000

On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> Yoav Nir writes:
>> I’m not entirely comfortable with calling something a MUST NOT when all we
>> have is conjecture, but I have no love and no need of those DH groups.
>
> Same here, and it also makes it so that we cannot say our
> implementation is conforming rfc4307bis, even when we do already have
> support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to
> implement algorithms in the new document, but we do also have code to
> propose the RFC5114 MODP groups, if user configures them to be used.
>
> Changing that is of course is very easy to do in implementation, but
> before this is deployed etc will take some time, and there is change,
> that some customer has explictly configure RFC5114 2048-bit MODP group
> in use, and by removing that we suddenly break their existing
> configuration.

In sane protocols the default MTI ciphersuite is always ready to be
used for exactly this reason. IKE's extensively flexible configuration
knobset was not a good idea for this reason.

>
> It is always annoying to explain to customer why we explictly broke
> their existing configurations unless there is real security reason for
> it. Looking that the paper, this only applies to the 1024-bit MODP
> group in RFC5114, even the paper says that 2048-bit MODP groups are
> safe, even if they would have same backdoor.
>
> We are already downgrading normal 1024-bit MODP group to SHOULD NOT,
> and this would make it two reasons to make RFC5114 1024-bit MODP group
> to SHOULD NOT (too short, and might be backdoored), so perhaps the
> compromize can be to make RFC5114 1024-bit MODP group number 22 to
> MUST NOT, and keep the groups 23-24 as SHOULD NOTs.

This seems reasonable to me.

>
> Anyways we need to modify the rfc4307bis text and add reference to
> this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be
> used.
>
>> I don’t believe anyone else depends on these groups (at least in
>> IPsec), so I’m fine with such a change.
>
> I do not think people depend on them, but I assume there is quite a
> lot of implementations there that can be configured to use them if
> explictly asked, thus making them MUST NOT will make it so that those
> implementations will not be conforming rfc4307bis.

That's sort of the point. We want these implementations to NOT support
these groups, just as RC4 die-die-die meant TLS implementations no
longer support RC4.

> --
> kivinen@iki.fi
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.