If I understand things correctly, the solution is already available
in DKIM today. It involves signer configuration (sign for N+1
instances of each header that is covered by the signature) and
requires no change in protocol or semantics. It merely hardens the
DKIM signature and I see
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Wietse Venema
Sent: Friday, October 08, 2010 1:16 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
What I describe would
Wietse:
What I describe would be a best practice application of DKIM
mechanisms that already exist.
Mail is signed as if there are N+1 instances of each header that
is covered by the DKIM signature. The verifier will then fail if
any such header is added after-the-fact.
With this, there
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Wietse Venema
Sent: Friday, October 08, 2010 1:26 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
Dave CROCKER
Hence my original post with the suggested special consideration text
for section 5.4 in regards to 5322.from.
--
HLS
Wietse Venema wrote:
Wietse:
What I describe would be a best practice application of DKIM
mechanisms that already exist.
Mail is signed as if there are N+1 instances of each
With this, there is no need to rely on enforcement mechanisms
outside DKIM, such as the correct implementation of RFC 5322.
I would suggest constraining that to include only those fields that are
0-or-1 in RFC5322 Section 3.6. For example, doing this with Received:
is begging for
I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.
Except that's not the situation we have here.
a) Author creates a 100%
On 10/07/2010 05:01 PM, John R. Levine wrote:
I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.
Except that's not the situation
this being some sort of existential threat. Can someone come
up with a scenario where this really could be evil and isn't
trivially fixed by... making spam filters insist that they're
really receiving valid 5322 as one of their rules?
If one does real whitelisting based on valid signature
I'm scratching my head to see if there is any advice we can offer to make
signing and verification more robust while not changing the behavior of
existing code for normal (for some definition of normal messages).
A) You have to sign either all occurences of a header or none of them, and
101 - 110 of 110 matches
Mail list logo
