Re: [Dcrup] I do not like the dcrup ECC document

denis bider <denisbider.ietf@gmail.com> Fri, 07 July 2017 23:29 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD412EC41 for <dcrup@ietfa.amsl.com>; Fri, 7 Jul 2017 16:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 Pf6XQr10FjDe for <dcrup@ietfa.amsl.com>; Fri, 7 Jul 2017 16:29:38 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 86CE7129AEB for <dcrup@ietf.org>; Fri, 7 Jul 2017 16:29:38 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id p207so15098145yba.2 for <dcrup@ietf.org>; Fri, 07 Jul 2017 16:29:38 -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=YG6W01JE1dfj2DEKYLgHxp057WAyLXurKKgQqLoDrrA=; b=Z3zY2HSbXyBA+tFDaY7KccsYQJH5G3Z9embIyDlMVKPEZgw2OgF68cGJSdSA3hq0kh 8DdxlABPcBepJbr+D16DgIXKdqGAT2dHxO5as9SX/ZN8WAJUvahoJmNMgEQNILdPoT5M 149+8Z/+7TYyBMS3mMsI1be/JHk0OZZ5tVcvoote9gno5aSg4FbSCaS299g+9qTS3oDx HxL+TcgZTJ+Be0DMovzo5IZu4SEXJS2ZgHWNQVfUSrmFsxJwroFiXO3BdB6WyGkwXY8s iJFR6+h1nCiFPVELZBZLejgyJGbKrcJQNMnZwZyUzexfrtTQRwoy6DmH1oxvFD05P9YJ 4ZnA==
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=YG6W01JE1dfj2DEKYLgHxp057WAyLXurKKgQqLoDrrA=; b=EPBkkvyuEhEMhSK85RJnhcpbcBO8dnfRe22bCEiz5xJ+gsrjYP4hMdVHhdfTWBt89G 3PydCRP3sj+luSvo1yVhEZ9INFoB3Exu/Q8Z6aqj5WDMfewiGpZT9YtzioWYqNxg608+ DC0XvdWGDnFUzcOHwObWKCJT4RyaqygK3xkC6Bepp9/JEnyKplC4iCb6YW2/csJMjq4O +E82eJKmAb+WA1XpLRg6sQfSTwM3eJUStgVkiV86ZILQJMztGh0aYKChU9CAlIWelSSM 7CeNnnHoupvRFkeijH4AZUC+Ll6rmNGCsf8t8s6h+ZlmxJoIZE3gLdqVBBh68BWsxD5a rj4A==
X-Gm-Message-State: AIVw111Eo5u4cNBP8LE2lfpMb4YXHJt3AGn9ocb2c+/wyNXYKw5fmbNZ ga13wuBxffm0k9bbmyXaSh8aEWZ+EQ==
X-Received: by 10.37.205.133 with SMTP id d127mr6376885ybf.215.1499470177790; Fri, 07 Jul 2017 16:29:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.173.203 with HTTP; Fri, 7 Jul 2017 16:29:37 -0700 (PDT)
In-Reply-To: <6025949.j6Hv4PBd49@kitterma-e6430>
References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <D8F33B2B-42CB-4057-9567-CDEC37369C21@nist.gov> <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> <6025949.j6Hv4PBd49@kitterma-e6430>
From: denis bider <denisbider.ietf@gmail.com>
Date: Fri, 07 Jul 2017 17:29:37 -0600
Message-ID: <CADPMZDDs5iwe+rz-rQCsX=PzkxHh6ojPSZEDK3ab_ZEfg6EbaQ@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dcrup@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c189eec4c80c30553c29b43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/-T7m_CyRHYvFsnqmxJ-tcxT_9Gc>
Subject: Re: [Dcrup] I do not like the dcrup ECC document
X-BeenThere: dcrup@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DKIM Crypto Update <dcrup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrup>, <mailto:dcrup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup/>
List-Post: <mailto:dcrup@ietf.org>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrup>, <mailto:dcrup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 23:29:41 -0000

Agreed. It is a substantial advantage of DKIM as-is that the only algorithm
that needs to be supported is RSA.

Adding "rsafp" and one elliptic curve option makes for 3 algorithms to be
supported by everyone. That's plenty.

If anything, I'd cut "rsafp" so that there are only two options (RSA and
EC). Users affected by crudware can migrate to EC instead of large RSA
keys. But this might not be a popular option.

On Fri, Jul 7, 2017 at 9:30 AM, Scott Kitterman <sklist@kitterman.com>
wrote:

> On Friday, July 07, 2017 03:09:39 PM Salz, Rich wrote:
> > Since the entire IETF is moving to the Edwards curves, is there a
> deployment
> > requirement for FIPS P256 now?  Or can those who need FIPS algorithms for
> > signing keys stick with RSA?
>
> > If P256 is needed now, then I think we should have one document that
> covers
> > Ed25519 and P256, or at least modify the draft names and titles to make
> it
> > clear that this is “a” choice, not “the” choice for ECC DKIM signatures.
>
> > If DNS operators aren’t well versed in crypto, do we need to be concerned
> > about them deploying DSA?
>
> Every option you add, implementers need to add signing and verification
> code
> for (even if it's just more calls to appropriate libraries).  As far as I
> know
> there's no security urgency to using ECC now.  The reason to add it now is
> to
> future proof the protocol.
>
> If there is a transient issue with some implementers not using ECC due to
> internal policy reasons, I don't think that should affect the WG's path.
>
> Adding one ECC DKIM method is enough.  "For now" anyone who doesn't like
> the
> curves the IETF picked can stick with RSA.  If the IETF needs to be making
> different choices in the ECC arena, I don't think this is the right WG to
> work
> that out.
>
> So far I'll have to add the sha256 hashed DNS record approach and one ECC
> method.  I think those are reasonable.
>
> Now maybe it's maybe two ECC schemes and adding PSS in addition to
> supporting
> PKCS#1v1.5 (mentioned in Review of draft-ietf-dcrup-dkim-crypto-03) plus
> the
> hashing.
>
> Every single option has to be widely deployed by both senders and receivers
> before it can realistically be used in the field.  If we just keep piling
> on
> the options it gets insane.  Maybe I have to sign a message seven times to
> get
> interoperability:
>
> rsa-sha1 (because some people use ancient stuff)
> rsa-sha256
> rsafp
> rsa-sha256 PSS
> rsafp PSS
> ECC Ed25519
> ECC P256
>
> If we specify too many new options, that will ensure none of the them get
> deployed until there's a disaster discovered around rsa-sha256.
>
> Personally, I've started work on rsafp and plan to do Ed25519, but there's
> no
> way I'm up for coding more options just because someone thought it'd be a
> nice
> idea.
>
> Scott K
>
> _______________________________________________
> Dcrup mailing list
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>