Dne 18. 08. 24 v 0:05 Steffen Nurpmeso napsal(a):
Murray S. Kucherawy wrote in
<cal0qlwa885tsxoydayo88rljgzmviennt9ed6zxf8yfd-et...@mail.gmail.com>:
|On Sat, Aug 17, 2024 at 12:36 PM Steffen Nurpmeso<[email protected]>
|wrote:
|>|> Instead there should be a (yet another) DNS entry that notifies
|>|> whether a host DKIM-signs its emails, or not.
|>|> Then receivers can peek that state.
|>|> This idea in several forms was posted here in the past, without
|>|> responses.
|>|
|>|Why do we need yet another one of those?
|>
|> Domains need to be able to signal From: parsers presence of DKIM
|> signatures.
...
|As you point out this is very similar to ADSP, which never got much
|traction and still suffers from the same problems DMARC does regarding
These were other times.
Since then myriads of possibilities have been added to generate
"more identification value" of an email's source, even "over the
corner", and what not.
Maybe the significance of ADSP was therefore simply not
understood.
Yes.
Like i said, the sentence
o signature verification failure does not force rejection of the
message;
was possibly misunderstood by the entire IETF.
Read over it.
Throw it away.
It was an easter-egg.
Because -- *why* should it be like that?
Signature verification is comparable to what happens during a TLS
handshake. It is a cryptographic operation using currently
non-broken algorithms.
It simply does not get any better than that.
|indirect mail flows. I think you'd need to address those as well. Do you
|have something in mind?
I must admit i currently do not know what you are talking about.
I do not follow DMARC and ARC development except when something
comes in via announcements, i often glance over drafts and such.
To me there are exactly two possibilities for email messages,
regardless of how many stations the message has passed:
1. the (core of the) message is unchanged
I would like to correct to the "signed part of message is unchanged",
because of problematic length tag in DKIM-Signature header.
2. the message has been altered
And whoever creates a DKIM signature
1. has access to the private key
2. has to have write access to the DNS zone of the domain the DKIM
signature applies to (to place the public key)
If a message has been altered, all bets are off.
Again, better to wrote if signed part of message has been altered.
Anyone can add anything after signed part, event. anyone can add a
extensions in case that you does not have signed appropriate mail headers.
This is a tremendous failure of the IETF and those giants which do
it the way they do it.
Funnily one of those many drafts mentions this,
draft-chuang-dkim-replay-problem said in 2023 (!)
Mailing List: [.] nearly always break any existing DKIM signatures.
I mean there is RFC 6377.
But then again there is only thing plain, the original message no
longer exists. It is as simple as that.
In my humble opinion the solution is
- announce this change in the DKIM signature via a new, backward-
compatible flag
- create your own DKIM signature for the altered (new) message
(thus)
Finished. User interfaces should have been designed to signal
this to users. It cannot be automatized. You cannot warp
reputation around the corner, what chuang writes in the mentioned
draft
ARC [RFC8617] is a protocol to securely propagate authentication
results seen by Mediators
is pure rubbish in my opinion, sorry. Yes the propagation is
secure with lots of effort, but the result cannot be trusted,
especially not by minor sites somewhere in the corner of the
internet. And if, you could very well include it in your DKIM
signature. No need for myriads of processing, DNS lookups,
signatures and all that. No.
No. If you have to alter the message, flag that this has
happened, and user interfaces need to be changed over time so that
users are given possibilities to white/allow-list some specific
party which does that, like a mailing-list.
Google and/or KI may even (offer) auto-pilot(s for) *that*, simply
by tracking their users: ie, if a thousand people say "yes" to
some IETF mailing-list, there is a high probability this is ok.
(But it is not more than that, never. Without a real person.)
Ie, you have to rewrite From: and all that, this ship has sailed,
and someone on this list posted years ago, that he "does not know
how to do that", and i do not, either.
And i am now fine with that, after fighting it for long.
It is just the actual environment as it is that makes this bad.
By my meaning, ARC has lot of problems, like DKIM, but make it worse:
1) Because there are no policies for DKIM and ARC (moving ADSP to
historical standards was a mistake in my opinion, moreover it only
covered DKIM), it is not possible to provide the recipient with
information about the signing policy. The recipient only detects the
existence of DKIM and ARC signatures for each individual technology
separately.
2) ARC depends on the first trusted (generally known) hop. If it is not
trusted or not accepted for any reason, the whole chain of signatures is
useless bunch of bytes.
3) In case that the ARC is not signed at the beginning, the path to the
first trusted hop is untrustworthy, and ARC is useless bunch of bytes.
4) If the attacker removes ARC headers and there is no policy enforcing
ARC, there is a problem again. Protection depends on (SPF+DKIM) and
DMARC only.
5) E-mails use the shoot-and-forget approach for ARC and DKIM, when the
validation of signatures depends on the existence of a DNS record. Since
this is checked by the recipient's server, it is justified. Thus,
historical e-mails cannot be validated and it is difficult to come up
with a procedure that would allow this. The only viable alternative
would probably be a PKI. A similar problem exists with digitally signed
archive documents. However, this procedure cannot be directly
transferred to the e-mail environment.
6) What is the worst, in some conditions that technologies could provide
false meaning of trust.
And regarding DKIM signatures of "all the MTA hops along the way",
if that is still true, they are fine.
One *could* build up some data stock with the involved host names,
so that in case of DKIM signature breakage different steps can be
taken, ie, "Organizational Trust" as of RFC 5863 could be fed with
this. This is of course true for ARC, too, but i want to remark
that here it is only about "service quality", not about "believing
authentication over the corner".
Greetings, and a nice Sunday i wish.
--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)
--
--
-- --- ----- -
Jan Dušátko
Tracker number: +420 602 427 840
e-mail:[email protected]
GPG:https://keys.dusatko.org/2E7D58B90FC2867C.asc
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
