[Dcrup] Re: [standards] [Editorial Errata Reported] RFC8463 (7930)
Steffen Nurpmeso <steffen@sdaoden.eu> Wed, 15 May 2024 00:18 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 CA33AC1840D6; Tue, 14 May 2024 17:18:29 -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="bTY2EFk4"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="jPbNYrpn"
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 C-dtb6zLZmTz; Tue, 14 May 2024 17:18:25 -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 C5406C180B7D; Tue, 14 May 2024 17:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1715732299; x=1716398965; 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=VF4hM6/ewbrbvajslDHdSG+K3M1rX215NL0iUfNBS54=; b=bTY2EFk4MKkpwE/0gQbLu3PxuZbvL0rGQZEjyzN6D+mFbJIG/BW3hDMubjPM5QneeFTdrzr8 6xu1uz+YKLYMolE4GUCDYd5gz0IekcsR77mUqcFyzP2DxskVKLr0HA5hifFTmKQ5GAcTi85/4b PCj2WKAmaBuBNyj2L9h2ou4ZbpbMeGsjzHF3ZF8+PgA5ECkICaunpdrl05sIVTyYKQ9kOFP9EA KPwftnZZE1y1Xv/jG67oD3NdWzvMVpBmJX1VRbbVGqgFPhQn7AegMxhxJwz6DLrtji/rZnDUjh HN276xArsNNozdGMawfPHw9in3zPXLUlM0bgWYssVYT/i7+g==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1715732299; x=1716398965; 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=VF4hM6/ewbrbvajslDHdSG+K3M1rX215NL0iUfNBS54=; b=jPbNYrpnQDWUc8E2/jRjhlcWBUBmt53OSCWcRBv8GkbdlSiNPG1GgW8FeCcTGOlL9tFxRoDg WGVGD7s7zoTGCA==
Date: Wed, 15 May 2024 02:18:17 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <20240515001817.saYJ-VOe@steffen%sdaoden.eu>
In-Reply-To: <ZkLM72PMJeWpet5C@chardros.imrryr.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>
Mail-Followup-To: Viktor Dukhovni <ietf-dane@dukhovni.org>, Hector Santos <hsantos@isdg.net>, "Murray S. Kucherawy" <superuser@gmail.com>, dcrup@ietf.org, ietf-dkim@ietf.org, 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: H6RQAHSR3JSAWEEZ4UIIO3IC55B7Z6SV
X-Message-ID-Hash: H6RQAHSR3JSAWEEZ4UIIO3IC55B7Z6SV
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: Hector Santos <hsantos@isdg.net>, "Murray S. Kucherawy" <superuser@gmail.com>, dcrup@ietf.org, ietf-dkim@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Dcrup] Re: [standards] [Editorial Errata Reported] RFC8463 (7930)
List-Id: DKIM Crypto Update <dcrup.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/C2jG_n4G9EAOkJgcx07NK1JzG7Y>
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>
I take John R Levine off, as he bounces my emails. I add ietf-dkim. Viktor Dukhovni wrote in <ZkLM72PMJeWpet5C@chardros.imrryr.org>: |On Mon, May 13, 2024 at 10:32:59PM +0200, Steffen Nurpmeso wrote: |> "It is ok", but i want to say again (there were some private |> emails and i have forgotten where i said what, i am talking too |> much, anyway) that RFC 8463 uses *three* digests, whereas RFC 6376 |> wants *two*. | |The main disconnect here is that you're hyper-focused on implementation |details, while the IETF deals with *specifications*. (It should take more care for the former, .. if you look around.) |The specification is clear and concise: | | The Ed25519-SHA256 signing algorithm computes a message hash as | defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as | the hash-alg. It signs the hash with the PureEdDSA variant Ed25519, | as defined in RFC 8032, Section 5.1 [RFC8032]. Example keys and | signatures in Appendix A are based on the test vectors in RFC 8032, | Section 7.1 [RFC8032]. | |Yes, this results in a different code path for RSA vs. EdDSA, due to API |differences in, where RSA signing typically includes the digest |operation, while pure EdDSA over a pre-computed message digest does not. The API difference is that the latter do not allow "registering" aka "passing through" a message digest that is part of the "digest-sign" operation, because "they" have a built-in message digest. I want to point out one thing before you go into the wrong direction, from my point of view, at least. The non-"EC" (the four letter MTA maintainer wrote ECS, OpenSSL umbrella them under OPENSSL_NO_ECX) algorithms like RSA allow for life cycles like Init .. Update .. Update .. Update .. Final Whereas those like the one we talk about here only alow one-shot operation. They mostly do not even allow to use the API used for that purpose for decades, but only DigestSignInit .. DigestSign (where Init is not allowed to specify a user supplied message digest.) This is because they internally want (even several passes) over all the data to be signed, including (several) message digest(s). |This may be a modest inconvenience to an implementor, but so be it. | |If there is a issue of clarity it is actually in RFC6376, where the Well, maybe yes, but not (from my point of view) because of what you now explain (you are the expert there, i do not even start thinking).. |signature is described as a private-key (decrypt) operation over a |pre-computed signature, but in fact for RSA what is used is an |RSAwith<SomeHash> hash and sign operation. |As explained upthread, the difference is the presence of the hash OID |in the signed payload, which consists of: | | - PKCS#1 padding | - Hash algorithm OID | - NULL parameters | - digest octet string | |Where a literal reading of RFC6376 might have expected: | | - PKCS#1 padding | - digest octet string | |Because the algorithm signalling in the DNS TXT record, and, with the |former, a naïve implementation might not check that the hash used in the |signature is actually the one promised by the DKIM DNS record. One, |might, e.g. accept an RSAwithSHA1 signature of the same headers and |DKIM-Signature template (with "b=" empty). | |There really ought to have been more text in RFC6376 about what's |actually expected, than just: | | NOTE: Many digital signature APIs provide both hashing and | application of the RSA private key using a single "sign()" | primitive. When using such an API, the last two steps in the | algorithm would probably be combined into a single call that would | perform both the "a-hash-alg" and the "sig-alg". Maybe yes, there is need for clarification. To reiterate, RFC 6376 says The Signer/Verifier MUST compute two hashes: one over the body of the message and one over the selected header fields of the message. And then it says In hash step 2, the Signer/Verifier MUST pass the following to the hash algorithm in the indicated order. It also says body-hash = hash-alg (canon-body, l-param) data-hash = hash-alg (h-headers, D-SIG, body-hash) signature = sig-alg (d-domain, selector, data-hash) ... hash-alg: is the hashing algorithm specified in the "a" parameter. ... signature: is the signature value produced by the signing algorithm. sig-alg: is the signature algorithm specified by the "a" parameter. So if i now paste its data-hash: is the output from using the hash-alg algorithm, to hash the header including the DKIM-Signature header, and the body hash. then it is clearly against my point of view... |Because that's not actually accurate, due to the inclusion of the digest |OID in the signature payload in the "single" primitive. ...but the above says "two hashes". But despite that. An Ed25519 sign operation alone creates three SHA-512 digests which are incorporated into several further calculations. Whereas for RSA it is, to the best of my knowledge, crucial to let it pass over as few bytes as possible (for encryption as such i think OpenSSL will refuse to do so after a certain limit), for EC with its embedded digests it may be more expensive but even beneficial to push more data rounds onto the embedded digests. So maybe, and in hindsight to the RFC that i would try to publish in fall if i am allowed to and if the email giants still have not moved towards this RFC 8463, it might make sense to adjust the data-hash in that it may come from hash-alg or be included via sig-alg. --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