Comments inline. - Phillip
> On Aug 21, 2025, at 9:39 PM, Murray S. Kucherawy <[email protected]> wrote: > > On Wed, Aug 20, 2025 at 2:06 PM Phillip Tao <[email protected] > <mailto:[email protected]>> wrote: >> > so if they're not going to sign it makes sense for them not to verify >> > either. >> >> I don't think this necessarily follows from the preceding statement. > > I think he meant: Client-to-client signing means the clients at each end need > to be able to do their bit, but if one end can't, then the other is moot. I think "client-to-client" is meaningful in the context of confidentiality. When you're encrypting something, you're encrypting it _to_ someone, and expecting that only that specific party can decrypt it. Then, client-to-client/end-to-end has clearly different security characteristics than MTA-to-MTA. However, in the context of signing, I don't see how "client-to-client" really means anything. When signing something, you're just establishing authenticity generally, and there's no way to specify (or limit) who is allowed to verify that authenticity. > > Instead, signer-to-verifier operation where the signer is a domain MTA but > the verifier is an MUA is possible. But you run into things like rotating > keys causing signatures to be invalid. I think we talked about that > upthread. Yep, there are several problems. I think we should work on improving all of them. > Also some operators use very short "x=" values as a way to mitigate replay > attacks (contrary to the standard), resulting in what you might think of as > false negatives. An explicit goal of DKIM2 is to prevent replay attacks, so I think this workaround should no longer be needed. > There are probably other threats to this model I'm not thinking about without > more coffee. > > Overall, I'd say client-side verifying might work for some or even most > cases, but I don't think I'd consider it to be very reliable. It's decently (but not _very_) reliable today (with DKIM1), but I don't think we need to just take that as a given. There are specific reasons for that unreliability, and I think many of them can be solved. And I don't think we necessarily need to definitively solve _all_ of them, but we can solve some of them and take steps toward improving reliability for others. > >> However, we've found that there are other policy decisions we want to apply >> to messages based on DKIM/DMARC status. For technical, security, and >> liability reasons, simply getting the DKIM/DMARC status from the >> Authentication-Results is not sufficient for this. > > Can you explain why? This is exactly what A-R was made to do. The main issue with A-R results are that, for a MUA which is not limited to working with only a single mailbox provider controlled by the same organization, there's no (standardized/easy) way to establish trust that the A-R header was actually inserted by the MDA (i.e. section 7.1 of RFC 8601). > > -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
