[Dcrup] Re: [Ietf-dkim] [standards] [Editorial Errata Reported] RFC8463 (7930)
Steffen Nurpmeso <steffen@sdaoden.eu> Thu, 16 May 2024 22:29 UTC
Return-Path: <steffen@sdaoden.eu>
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 8B014C14F749; Thu, 16 May 2024 15:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sdaoden.eu header.b="cHx96fgX"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="xTe0K2ZL"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hjzJRGKl1y1; Thu, 16 May 2024 15:29:31 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD7AC15107F; Thu, 16 May 2024 15:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1715898564; x=1716565230; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=Ec5m0DOS3HbMCObYEykmH4U2Y2SGGU1QzhQhjkK9Mv8=; b=cHx96fgXLVyN9FqTohZwjV8gjzwp8P/6mhQgid1Flz+cUtOUChPNrszsiAXOEESUoqzodNbK mUAuKchL2jOqFpnTO/cQRDiDpqlWj5Ti8B76Zc94T4I66tOmvwi0cBJEnKkQ68NtwaQ0v65UJ2 wG7kwfCSJAk2RvoDZg6vMMyjN7BxVx1X4pdicfsJN5AYeZ0EhYUkiZG6ZaRfpGYLZBhbvLkzoM IymqNwT3JWxj1oNgmAuF6ZA0jHiATvz6EBeNgrrKuEVGcKhCI0xCArl3JMEkPkV3BWAIcyIskf S0hnwapeEaFfQmCK5JFZEjQ+ss+bomQIradKyTVHjWVjAIiA==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1715898564; x=1716565230; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=Ec5m0DOS3HbMCObYEykmH4U2Y2SGGU1QzhQhjkK9Mv8=; b=xTe0K2ZLE1wRAjG8Gto78F/xEBaNF2LU0vP2C4QA3qrqqdTYyzddskzsf+JF7XghydDLDeqz jyxZ9JNuaiLWBQ==
Date: Fri, 17 May 2024 00:29:22 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <20240516222922.RlI6iUKT@steffen%sdaoden.eu>
In-Reply-To: <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>
References: <ZkAOictS1ygyIBZe@chardros.imrryr.org> <20240512005258.N-lL8YIA@steffen%sdaoden.eu> <CAL0qLwYPtxxDhYEjH0D5YkcXBf6Qy6Xcux7PdvFtwhJzpaUxyg@mail.gmail.com> <ACD165BA-9195-480E-9FA0-44A44097E6A8@isdg.net> <20240513203259.hFdFtvyd@steffen%sdaoden.eu> <ZkLM72PMJeWpet5C@chardros.imrryr.org> <20240515001817.saYJ-VOe@steffen%sdaoden.eu> <CDA9C77F-A74A-4303-AE9E-3E71661AA490@isdg.net> <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>
Mail-Followup-To: Viktor Dukhovni <ietf-dane@dukhovni.org>, ietf-dkim@ietf.org, dcrup@ietf.org, Hector Santos <hsantos@isdg.net>, Steffen Nurpmeso <steffen@sdaoden.eu>
User-Agent: s-nail v14.9.24-621-g0d1e55f367
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 24LK43VDMPKAWTBGZ3OAS3QNU2X4E7G6
X-Message-ID-Hash: 24LK43VDMPKAWTBGZ3OAS3QNU2X4E7G6
X-MailFrom: steffen@sdaoden.eu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dcrup.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ietf-dkim@ietf.org, dcrup@ietf.org, Hector Santos <hsantos@isdg.net>, Steffen Nurpmeso <steffen@sdaoden.eu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Errata Reported] RFC8463 (7930)
List-Id: DKIM Crypto Update <dcrup.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/qfgIQaYH74gv2In3csYknrmDOE8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Owner: <mailto:dcrup-owner@ietf.org>
List-Post: <mailto:dcrup@ietf.org>
List-Subscribe: <mailto:dcrup-join@ietf.org>
List-Unsubscribe: <mailto:dcrup-leave@ietf.org>
Viktor Dukhovni wrote in <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>: |> On 16 May 2024, at 10:02 AM, Hector Santos <hsantos=40isdg.net@dmarc.i\ |> etf.org> wrote: |> I don’t wish to oversimplify here, but I wonder if the confusion \ |> is with the idea that in order to support RFC8463, a complaint implement\ |> ation would have to sign two DKIM signatures for backward compatibility. \ |> One DKIM signature using SHA256 and a second signature using Ed25519. | |No, you're conflating completely different constructs, because SHA256 \ |is NOT a signature, it is a message digest. And i think he mentions an interesting point, given that people on the dkim list said that they use the Ed keys since 2019, and "without problems", which is i think the correct citation. That is five years and still you need to DKIM-double-sign your emails, because major email player with which you have to be compatible to simply do not follow this spec. Truy, i have heard that "just use the rsa-sha256 and be good" quite some times in the past months where i was so deeply involved in this topic. It surely results in smaller messages and less resource consumption, .. especially if there is no light on the horizon that the situation will change for a better. ... [resorting for effect] |Nevertheless, the specification is clear enough, and a slightly different \ |code path for the new signature scheme is fine. No. That is not necessarily a necessary evil. We have that problem with some other email standards, where each and every one invents its own [un]"structured header" format, just slightly different, but which needs to be addresses specifically. You can see how serious the people treat the standards if you look into the code, you see the blurred corners and the generalized parsers. This can be said about the plain DKIM RFC 6376, too, as it uses VCHAR; i presumed it did so for simplicity as that means "no comments", no quoted-pairs, no quoted-strings etc, and so it is. On the other hand noone would be hurt if the entire IETF email standards would focus on RFC 5322 and RFC 2045 with their near 50 years of defined content, and clear syntax elements like atext and the mentioned, and rules like key=value or key="value" etc, instead of inventing things which look easy but are entirely different like key(FWS)=(FWS)value1(FWS that counts)value2, and similar monsters. (Again: artificially complicated.) I do not know why this can be seen all over the place, but it is there. Sure, yes, you can, .. but i at least would not. (In the meantime if have changed the post-release code of the little thing i have written so it is generalized via "extern_md" and "sign_md" booleans, but i would be eager to drop the former again.) ... |Nothing of the sort, the computational costs are trivial, there is \ Well if you have to place two further ARC signatures then maybe. The following Ed25519 computations are less than trivial for sure. On the OpenPGP list i think it was where they had a deeper look at "whether it should be SHA-256 or SHA-512" (for whatever purpose), and it depends a lot on crypto extensions, and 32-bit or 64-bit CPUs etc. And i think the IETF email group should possibly step down from usurping the small CPUs of the little servers of poor students, there is also the TLS and HTTP community which longs for taking its toll. |some additional code required for Ed25519 support, because |instead of using a single Digest+Sign primitive in, e.g., OpenSSL, \ |the caller needs to first compute a message digest, and |then pass it to Ed25519 for signing. This is OK. One might argue \ |that this should have been either pure Ed25519 over the raw |data (contrary to the text of the base DKIM RFC, but aligned with how \ |it ultimately handles RSA), or, else Ed25519ph which is |explicitly design for hashed input (but APIs for which are not yet \ |mature in OpenSSL). Of course i give in because "ultimately" the RSA key signs the digest of the headers, just like the digest of the headers is passed into the Ed25519 algorithm. But again i will point to the possible future in fall this year, when i would try to write a draft that changes this, because i see no reason why we must be totally fixated on it, *if* the sig-alg contains (even extensive) digesting itself, we could very well "simply pass the headers", like the developer of the four letter MTA wrote, and the result will not be less secure or or lesser quality, but possibly even better. --End of <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
- [Dcrup] [Editorial Errata Reported] RFC8463 (7930) RFC Errata System
- [Dcrup] Re: [standards] [Editorial Errata Reporte… John R Levine
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Alessandro Vesely
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… John R Levine
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Viktor Dukhovni
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Viktor Dukhovni
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… John R Levine
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Viktor Dukhovni
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Hector Santos
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Alessandro Vesely
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Viktor Dukhovni
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Rebecca VanRheenen
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Alessandro Vesely
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Viktor Dukhovni
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Steffen Nurpmeso
- [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Er… Hector Santos
- [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Er… Viktor Dukhovni
- [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Er… Steffen Nurpmeso
- [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Er… Viktor Dukhovni
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Murray S. Kucherawy
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Murray S. Kucherawy
- [Dcrup] Re: [Editorial Errata Reported] RFC8463 (… Orie Steele
- [Dcrup] Re: [standards] [Editorial Errata Reporte… Murray S. Kucherawy