Re: [Cfrg] would it be a good idea for CFRG to try review algorithm documents?

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 11 December 2015 17:38 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011CC1B2D43 for <cfrg@ietfa.amsl.com>; Fri, 11 Dec 2015 09:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 iyPkduETCIQS for <cfrg@ietfa.amsl.com>; Fri, 11 Dec 2015 09:38:28 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 A8AD81A8A1E for <Cfrg@irtf.org>; Fri, 11 Dec 2015 09:38:27 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so74942684lbb.3 for <Cfrg@irtf.org>; Fri, 11 Dec 2015 09:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5gzzF3QyIAUNEbFO9wstiqDghdV7FiVERVhCfOuE6PQ=; b=nLWmSiy7ODVgic0/b8p8xnurXVzQu8XPmNkM59Rc3urMNL3GJArJxlAQp5h+7jnN7R p0F9nlNHQssjaqBX1+IrlF7TnFqpxytPRK/nOqE259SwNAASHUfuz1Nthls1rOKyzvpA 0+G/SkWX5wuA6KWHDOhnhr++Xidsf7ey92PkuDoioVeMNpywFgBi5f+W8UFqwfWu6HwO il1C49hJjWAc3WtKB5fdGtt0RtqGyyWJCb6whUktJ9EfskRMhXWTsJB32JUTXk2FRx05 3e6s7+KGMpS4XQE2iNTmcoQE0qk2sBza6z9v1zOAwRo0dYsKFtV5OnTtOKJdGpI5W7kG n+mw==
MIME-Version: 1.0
X-Received: by 10.112.199.194 with SMTP id jm2mr6972766lbc.109.1449855505819; Fri, 11 Dec 2015 09:38:25 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.1.227 with HTTP; Fri, 11 Dec 2015 09:38:25 -0800 (PST)
In-Reply-To: <876105koj1.fsf@latte.josefsson.org>
References: <5668D26F.2020200@cs.tcd.ie> <5668D7A3.1070103@cs.tcd.ie> <876105koj1.fsf@latte.josefsson.org>
Date: Fri, 11 Dec 2015 12:38:25 -0500
X-Google-Sender-Auth: 6TalOpn3EiSwB-9ZR8UjE5f-5O4
Message-ID: <CAMm+LwhnAFXqV_akV=V-P94rqddAAPBY1muY-_buSCuAY-HfaQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: multipart/alternative; boundary="001a11c33a52666f8a0526a2ca19"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Jy2K6xRpy80B5GTX9bD4atYAlFk>
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>, Nevil Brownlee <rfc-ise@rfc-editor.org>
Subject: Re: [Cfrg] would it be a good idea for CFRG to try review algorithm documents?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2015 17:38:30 -0000

On Fri, Dec 11, 2015 at 10:12 AM, Simon Josefsson <simon@josefsson.org>
wrote:

> Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
>
> > Hiya,
> >
> > The IESG has another of those conflict reviews on Dec 17. In this
> > case I doubt there's a process conflict (see below for details)
> > as this is documenting some more details of the GOST suite which,
> > as a national algorithm suite, kind of just is what it is.
> >
> > But as a non-cryptographer, I'd be happier if in future things
> > like this (or non-national "vanity" algorithm descriptions) had
> > gotten some review from CFRG, however I'm not sure if folks here
> > would be generally willing to do that kind of review.
>
> Wouldn't it make more sense for the CFRG to work on a document that said
> that vanity algorithms (state-sponsored or not) are harmful to Internet
> security, and should not be published as RFCs at all?
>
> In my opinion, the CFRG should recommend the best algorithms and
> approaches for network security uses (which may include state-sponsored
> crypto).  In my mind, that includes recommending a small set of
> state-of-the-art algorithms in each category of cryptographic primitive,
> and actively discourage proliferation of algorithms as we've seen that
> this reduce overall Internet security.  As a side-note, it is important
> that this doesn't come in conflict with the ability of deploying
> experiments -- so the CFRG could recommend that protocols include
> flexible negotiation approaches (the SSH model with text string
> algorithm names has been successful here -- the binary and regulated TLS
> model has not been as good).
>
> Otherwise I fell that the CFRG becomes a political rubber-stamp
> organization.


+1

I will just add that if the IETF wants to do text strings, I would prefer
they be URNs rather than in an IANA registry. The best way to avoid capture
of a control point is to eliminate it.

Back in the days before the cryptowars were the big issue, there was the
'cyberporn' circus when the establishment attempted to gain control over
the Web by scaremongering about pornography based on a ridiculous survey
that had found 80% of the material in the USENET porn newsgroups were
pornographic (I'm shocked).

As part of the legal strategy against COPA, the W3C got involved in an
effort to developing a labelling system for Web sites. Which of course the
would-be censors loved because after getting the bill through, the
Christian Right and Marxist Feminists could fight over control of the
regulation boards. Unfortunately the idiot in charge of the project tried
to build something that was meant work. So I proposed they use URIs as
identifiers for the labelling schemes. Once it was clear that there would
be no single nexus of control, the tactical alliance between the two groups
collapsed.


I see the situation with GOST as being very similar. The requirement to use
a state sponsored crypto will be used as a justification for stripping out
DNSSEC records that don't meet the state crypto requirements. Or at least
that would happen as soon as people started using DANE to secure
certificates.

Back in 1995 we could have easily used DNSSEC instead of X.509 as the basis
for distributing the WebPKI. The reason we didn't was precisely the fact
that it would concentrate control in one place and make that too much of a
target.