Re: [Ietf-dkim] DKIM Signature
Dave Crocker wrote in : |On 10/29/2023 1:51 PM, Jan Dušátko wrote: |> In my opinion, the verifiability of the place and time of origin needs |> to be addressed, which is one of the reasons to use DKIM: | |While I think I understand the basis for thinking that DKIM is relevant |to that determination, it isn't. It's semantics have nothing at all to |do with authenticating origination, nor certifying content. Note, for |example, that there can be (and often is) multiple DKIM signatures, |affixed at different time. This is why it is so important that ARC makes headers directly addressable in infrastructures that ignore the stack nature of email. |DKIM says the signer attests to having 'some' responsibility in |'handling' the message. That is fundamentally different than what your |text means. Still the sheer size of "good enough" (tm) RSA is consumes space and bandwidth, and, yes (do not laugh), electrical energy. And pushes towards TCP for DNS I still think ED25519 is not gracefully supported by all DKIM implementations because you cannot use a stream based approach, but must load the entire data "in memory", it is a one-off algorithm. (As is x448.) And some implementations simply decided it is too hard to implement. But the IETF *did* standardize this what you claim "overkill", no? OpenSSH (i am not a cryptographer; they are not either, i think, but they monitor very closely, what i think) did "also not do 448" but have chosen to experiment with post-quantum sntrup761, saying The sntrup761 implementaion, like sntrup4591761 before it, is public domain code extracted from the SUPERCOP cryptography benchmark suite (https://bench.cr.yp.to/supercop.html). To me the thing is, .. you know .., that even MD5 or the slightly hardened SHA-1 is still "good enough" for signatures, but most people ran away nonetheless, and today you see SHA-256 or SHA-512, or BLAKE (etc). And *if* the entire message has to be "loaded into memory" to be able to support new and modern algorithms, a lot becomes possible. Also i personally think of DKIM like i do for a passport. You do anything possible to make it unforgeable. I want a cryptographically verifiable path through the stack up to the origin. DKIM just never tried to offer the necessary hands to operators of mailing-lists etc to close the cryptographic gap. ARC will now do this, fully automatic. --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) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote: Dave Crocker wrote in : |On 10/29/2023 1:51 PM, Jan Dušátko wrote: |> In my opinion, the verifiability of the place and time of origin needs |> to be addressed, which is one of the reasons to use DKIM: | |While I think I understand the basis for thinking that DKIM is relevant |to that determination, it isn't. It's semantics have nothing at all to |do with authenticating origination, nor certifying content. Note, for |example, that there can be (and often is) multiple DKIM signatures, |affixed at different time. This is why it is so important that ARC makes headers directly addressable in infrastructures that ignore the stack nature of email. 1. I don't understand what you mean by "headers directly addressable in infrastructures" 2. I am pretty sure ARC doesn't do that 3. I don't understand how your response is relevant to what I wrote. 4. I don't understand how that is relevant to the current working group topic of a problem statement |DKIM says the signer attests to having 'some' responsibility in |'handling' the message. That is fundamentally different than what your |text means. Still the sheer size of "good enough" (tm) RSA is consumes space and bandwidth, and, yes (do not laugh), electrical energy. And pushes towards TCP for DNS Is your response suppose to have something to do with my statement? -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Dave Crocker wrote in <2bdbcfe0-4126-45b5-93a3-51ec4f8cf...@gmail.com>: |On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote: |> Dave Crocker wrote in |> : |>|On 10/29/2023 1:51 PM, Jan Dušátko wrote: |>|> In my opinion, the verifiability of the place and time of origin needs |>|> to be addressed, which is one of the reasons to use DKIM: |>| |>|While I think I understand the basis for thinking that DKIM is relevant |>|to that determination, it isn't. It's semantics have nothing at all to |>|do with authenticating origination, nor certifying content. Note, for |>|example, that there can be (and often is) multiple DKIM signatures, |>|affixed at different time. |> |> This is why it is so important that ARC makes headers directly |> addressable in infrastructures that ignore the stack nature of |> email. | |1. I don't understand what you mean by "headers directly addressable in |infrastructures" dkimpy of Scott Kitterman for example, in March this year: commit 264230308cd5b47cb24f115f9f71d1ac334a6ca6 ... fix correct AMS header selection When we are verifying the ARC seal we need to fetch the raw AMS header from the header list. But it's not enough to return the first one we find, since we may be interested in a different arc seal, we need to search for the correct ARC index. --- dkim/__init__.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dkim/__init__.py b/dkim/__init__.py index 73d095f808..c2e77e9074 100644 --- a/dkim/__init__.py +++ b/dkim/__init__.py @@ -1293,7 +1293,9 @@ class ARC(DomainSigner): # we can't use the AMS provided above, as it's already been canonicalized relaxed # for use in validating the AS. However the AMS is included in the AMS itself, # and this can use simple canonicalization -raw_ams_header = [(x, y) for (x, y) in self.headers if x.lower() == b'arc-message-signature'][0] +raw_ams_header = [ + (x, y) for (x, y) in self.headers if x.lower() == b'arc-message-signature' and b" i="+sig[b'i']+b";" in y.lower() +][0] |2. I am pretty sure ARC doesn't do that See above. |3. I don't understand how your response is relevant to what I wrote. The thread is about addition of another algorithm. I ... |4. I don't understand how that is relevant to the current working group |topic of a problem statement (that is what the thread is about) |>|DKIM says the signer attests to having 'some' responsibility in |>|'handling' the message. That is fundamentally different than what your |>|text means. |> |> Still the sheer size of "good enough" (tm) RSA is consumes space ... |Is your response suppose to have something to do with my statement? ... disagreed with you. *That* 'some' and 'handling' is a cryptographic signature operation. Even if the current non-ARC email stack at times breaks inner envelopes and thus places them and their producers in the twilight zone, to exaggerate that. But this deficite is surely soon addressed by ARC. The new algorithms also require significantly smaller certificates (ie my US-ASCII armored S/MIME RSA public key is 2139 bytes, my OpenSSH ED25519 one is 100 bytes, even though this compares apples and oranges.) And i reiterate what you did not quote, the Ed25519 algorithm with all the benefits is already standardized by the IETF. --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) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
