A) You have to sign either all occurences of a header or none of them, ...
B) Same as A, but limited to an enumerated set of headers that are
supposed to occur only once.
c) Same as B, but tell signers to use the h= trick to make verification
fail if extra headers show up.
John R. Levine:
a) Author creates a 100% compliant message
b) Signer signs 100% compliant message
c) Bad guy adds an extra header, making it non-compliant, and
sends it to someone
...
Mike, I only have vague recollection of the h= trick anymore...
You list all the headers you sign in
On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas m...@mtcc.com wrote:
I'm with Steve on this one. Forcing implementations of DKIM to
determine whether a message is compliant is a pretty high bar. ...
How can you claim it is a high bar when clearly it isn't.? All that the
implementor of a
Michael Thomas wrote:
On 10/07/2010 05:01 PM, John R. Levine wrote:
Nobody has signed a non-compliant message, so while there is nothing wrong
with Mike's advice, it completely misses the point.
You're right, it does miss the point. What I'm trying to get my
head around is whether this is
Wietse Venema wrote:
With this signer-side configuration solution, the verifier can
detect attempts to spoof any header that was covered by the DKIM
signature (spoof as in add a forged header, and hope that naive
programs will use the forged header instead of the authentic one).
So the
On Thu, 07 Oct 2010 19:18:19 +0100, Michael Thomas m...@mtcc.com wrote:
The larger issue here is would anybody rush out to close this MUST.
I think that it is highly unlikely that anybody is going to care at this
point. That goes for *any* new MUST, IMO: unless it's really a serious
protocol
On 08/Oct/10 07:00, John R. Levine wrote:
Having the signer put the extra junk in h= should make existing verifiers
do the right thing, although I doubt the bit of verification code that
checks for the non-existence of the N+1st header for N0 is well tested in
DKIM implementations.
+1, and
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, October 08, 2010 8:34 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
The whole discussion
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
I'm still cringing at the layering violation of fixing in DKIM the fact
that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to
enforce normative portions of that specification.
Is there precedent of this being done
Dave CROCKER:
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
I'm still cringing at the layering violation of fixing in DKIM the fact
that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother
to enforce normative portions of that specification.
Is there precedent
On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote:
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
I'm still cringing at the layering violation of fixing in DKIM the fact
that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't
bother to enforce normative portions of
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Friday, October 08, 2010 10:01 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
We want to re-submit
I'm still cringing at the layering violation of fixing in DKIM the
fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike,
don't bother to enforce normative portions of that specification.
The standard advice has always been to accept malformed mail and render
it as best you can,
On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
Sent: Friday, October 08, 2010 10:01 AM
To: ietf-dkim@mipassoc.org
Subject: Re:
On 08/Oct/10 18:33, Dave CROCKER wrote:
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
I'm still cringing at the layering violation of fixing in DKIM
the fact that many RFC5322 implementations, MTAs, MSAs and MUAs
alike, don't bother to enforce normative portions of that
specification.
Wietse Venema wrote:
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
Scott Kitterman wrote:
Murray S. Kucherawy wrote:
Doesn't DKIM try to detect modification of the portion covered by the
hashes, which is unchanged in this scenario?
For what I view as a very abstract definition of unchanged, sure. I think
adding additional From or Subject does change the
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 be
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:
On
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
Jeff Macdonald wrote:
Hence my original post with the suggested special consideration text
for section 5.4 in regards to 5322.from.
--
My apology to Jeff. It was not Jeff Macdonald who wrote the text
above. This was not an attempt at a spoof. I somehow replied to the
wrong message and
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
24 matches
Mail list logo
