--On 20 October 2010 15:42:32 -0700 Douglas Otis do...@mail-abuse.org
wrote:
But, hey, I'm on your side here. I think we should put a warning in
the RFC so that vendors are informed that they need to be sure
they're highlighting the correct header.
Why? There would not be a problem
On Wed, 20 Oct 2010 18:32:44 +0100, John R. Levine jo...@iecc.com wrote:
A reputation service can only say that a domain is
BAD
GOOD
or NO EVIDENCE AVAILABLE EITHER WAY.
I think the last case has to be treated pretty much like GOOD, otherwise
newcomers to the internet will never even
On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine jo...@iecc.com wrote:
good signature - good message.
Don't you mean
Good signature - authenticated message (that is, someone
accepts responsibility)
I think it needs to mean
Good signature - authenticated message (that is, someone
On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema wie...@porcupine.org
wrote:
My preference would be to enforce this within the existing protocol
(that is: send h=from:from:subject:subject...),
But that only copes with some of the scams that are possible; for full
protection you need
...
--On 20 October 2010 15:12:47 +0100 Charles Lindsey c...@clerew.man.ac.uk
wrote:
When I said good, I meant credible, not just one that mechanically
validates. I hope that we all agree that a signature from a domain about
which one knows nothing is not usefully different from no signature
--On 19 October 2010 07:31:58 -0700 Michael Thomas m...@mtcc.com wrote:
On 10/19/2010 06:18 AM, Wietse Venema wrote:
valid signature + good signer
+ no suspicious unsigned content - good message
Has nobody learned that good signers from good authors
can still be evil? I mean come
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote:
True, but there already are UI designs that indicate when a From header
is DKIM verified.
So you're saying that all a spammer has to do is to put on a throwaway
domain's signature, and the MUA will highlight at least
A reputation service can only say that a domain is
BAD
GOOD
or NO EVIDENCE AVAILABLE EITHER WAY.
I think the last case has to be treated pretty much like GOOD, otherwise
newcomers to the internet will never even get their messages accepted.
Heck, no. Treat it like there's no
On 10/20/10 8:10 AM, Ian Eiloart wrote:
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com
wrote:
True, but there already are UI designs that indicate when a From
header is DKIM verified.
So you're saying that all a spammer has to do is to put on a
throwaway domain's
John Levine wrote:
OTOH, we already have a SHOULD that tells MUA writers
to splatter the d= field somewhere in the GUI where the user
can't ignore it
Ugh, you're right. Now that I look at it, I'd like to completely
delete Appendix D, since it says some things that are just wrong,
i.e.
On 19/Oct/10 04:55, John Levine wrote:
There's a strong correlation between badly structured emails (SMTP,
MIME, HTML) and email that the recipient doesn't want to see.
You're right, but I think that's largely orthogonal to DKIM. If a
message has a good signature from a credible signer, I
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John Levine
Sent: Monday, October 18, 2010 10:55 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
There's a strong
On 10/19/2010 06:18 AM, Wietse Venema wrote:
valid signature + good signer
+ no suspicious unsigned content - good message
Has nobody learned that good signers from good authors
can still be evil? I mean come on, people, bot'd machines? This
is horrible advice.
s/unsigned/; and this
good signature - good message.
Don't you mean
Good signature - authenticated message (that is, someone
accepts responsibility)
When I said good, I meant credible, not just one that mechanically
validates. I hope that we all agree that a signature from a domain about
which one
True, but there already are UI designs that indicate when a From header is
DKIM verified.
So you're saying that all a spammer has to do is to put on a throwaway
domain's signature, and the MUA will highlight at least parts of the
message with green goodness? Surely our understanding of
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Monday, October 18, 2010 5:50 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
Why do we think such a sorting module can't/won't have
-Original Message-
From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk]
Sent: Tuesday, October 19, 2010 2:59 AM
To: John R. Levine; Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
True, but there already are UI designs
Sheesh, I think I've answered this at least three times now.
Well gosh, I sure do appreciate your patience in dealing with the rest
of us fools that might not share your view or have something else to
offer.
Sorry. But I could swear we had this exact exchange before.
In the
absence of a
On 10/19/2010 1:33 PM, John R. Levine wrote:
Re Security Considerations, it's better than nothing,
Not necessarily.
The current issue is part of a much larger one. We will not be dealing with
that larger set of security details because it is out of scope. Dealing with a
narrow piece of
: Monday, October 18, 2010 5:50 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
Why do we think such a sorting module can't/won't have the
intelligence to do the RFC5322 Section 3.6 checks?
Sheesh, I think I've answered
On 10/19/10 1:45 PM, Dave CROCKER wrote:
On 10/19/2010 1:33 PM, John R. Levine wrote:
Re Security Considerations, it's better than nothing,
Not necessarily.
The current issue is part of a much larger one. We will not be
dealing with that larger set of security details because it is out
] detecting header mutations after signing
And if we are not going to fix ADSP (yet), then the only way we can stop
that particular exploit is to fix DKIM.
Arguing that ADSP is a completely separate discussion will achieve
nothing.
If that's consensus, then we're on the slippery slope
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
--On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to be semantically identical to
On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote:
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
--On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why not
Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to be semantically identical to
h=from:from:to:to:
...
I assumed that the proposal applied only to headers rfc5322 says cannot be
duplicated.
That is a constraint that was not stated.
It is now.
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of MH Michael Hammer (5304)
Sent: Saturday, October 16, 2010 10:43 AM
To: Wietse Venema; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
What is the value proposition that DKIM offers that incentivizes people
to adopt it?
I'll take a crack at that: DKIM offers the MUA enough data to know what
parts of a message to be rendered can be considered valid inasmuch as
someone (the signer) took responsibility for it.
I have to
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Monday, October 18, 2010 5:25 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
Also, although I certainly do not purport to be a whiz at UI
difference between a green bar SSL page and one with no SSL. I don't want
to mess with the MUA at all, but rather use DKIM to help decide what
messages to show her and which messages to consign to the junk folder.
Why do we think such a sorting module can't/won't have the
intelligence to do
On Oct 18, 2010, at 5:50 PM, John Levine wrote:
difference between a green bar SSL page and one with no SSL. I don't want
to mess with the MUA at all, but rather use DKIM to help decide what
messages to show her and which messages to consign to the junk folder.
Why do we think such a
There's a strong correlation between badly structured emails (SMTP,
MIME, HTML) and email that the recipient doesn't want to see.
You're right, but I think that's largely orthogonal to DKIM. If a
message has a good signature from a credible signer, I expect I'd want
to show it to the user even
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Wietse Venema
Sent: Friday, October 15, 2010 5:10 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304
On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely ves...@tana.it
wrote:
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the problem
remains,
how is it a DKIM
-dkim] detecting header mutations after signing
But if there is no valid DKIM signature, the verifier will proceed to do
ADSP checks, and will reject the message if it sees that ebay.com is
'discardable'.
ADSP is a completely separate discussion. We're talking about advancing
DKIM here
On 14/Oct/10 20:09, Mark Delany wrote:
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, October 15, 2010 7:30 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations after signing
And if we are not going to fix ADSP (yet
On Oct 15, 2010, at 9:50 AM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, October 15, 2010 7:30 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
Sent: Friday, October 15, 2010 7:30 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations after signing
And if we are not going to fix ADSP (yet), then the only way we can stop
that particular exploit is to fix DKIM
Well a broken signature is morally equivalent to unsigned so Im not sure of the
potential harm...
On Oct 15, 2010, at 11:53 AM, Dave CROCKER wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com
Sent: Friday, October 15, 2010 11:59 AM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after
Subject: Re: [ietf-dkim] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so Im not
sure
of the potential harm...
And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of MH Michael Hammer (5304)
Sent: Friday, October 15, 2010 1:52 PM
To: Bill Oxley @ Cox; dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header
On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote:
On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To:
dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re:
[ietf-dkim] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so
@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust has been that it was
likely broken in transit. We failed to have the discussion of it being
On 10/15/10 8:40 AM, Mark Delany wrote:
h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?
Yes, it does. The only question is to devise normative statements
correctly, e.g. MUST duplicate From, SHOULD duplicate the rest.
This is _not_ a kludge. It is how
] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so Im not
sure
of the potential harm...
And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust has been that it was
likely
MH Michael Hammer (5304) wrote:
And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust has been that it was
likely broken in transit. We failed to have the discussion of it being
intentionally broken in transit as an attempt to
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John R. Levine
Sent: Wednesday, October 13, 2010 10:49 PM
To: dcroc...@bbiw.net
Cc: DKIM List
Subject: Re: [ietf-dkim] detecting header mutations after signing
What you
John R. Levine jo...@iecc.com writes:
DKIM support in an MUA? Yuck.
It's likely to be a long time before any MUA I use does anything with
DKIM, since I am not a fan of filtering mail while reading it.
An MUA does not have to do filtering in order to support DKIM. It could
display the
On Wed, 13 Oct 2010 17:34:32 +0100, Charles Lindsey c...@clerew.man.ac.uk
wrote:
But full 100% RFC5322 checking is extremely tedious, and is more that we
actually need.
What we want is more like
CHECK DKIM CHECK RFC5322 headers included in h= tag --
ACCEPT
where at least the
-dkim] detecting header mutations after signing
The bad guy (the phisher) provides two From headers, but only signs one
which, as DKIM is currently defined, has to be the second one.
His two headers are:
From: i...@ebay.com
From: i...@phisher.com
BUT many/most MUAs currently display
On Wed, 13 Oct 2010 19:27:29 +0100, Jeff Macdonald
macfisher...@gmail.com wrote:
If we can extract DKIM from the equation entirely and the problem
remains, how is it a DKIM problem?
I agree with this.
And even if there was a DKIM signature, it is the BAD GUY'S signature,
which should
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, October 14, 2010 7:32 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations after signing
This is true if the message
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the problem remains,
how is it a DKIM problem?
If the DKIM signature doesn't verify after signed headers have been altered,
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the problem remains,
how is it a DKIM
Alessandro Vesely wrote:
Correct. And the way that it fails to verify is h=from:from.
The only way that DKIM can consistently account for this exploit is by
amending section 5.5 Recommended Signature Content, and spell what
fields MUST/SHOULD be duplicated in the h= tag.
-0.5.
This is
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote:
On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly
wrote:
Having said that, if an MUA is going to present an indication of
DKIM PASS to the enduser, then a reasonable person would expect
some relationship between
On Tue, 12 Oct 2010 14:36:42 +0100, Hector Santos hsan...@isdg.net wrote:
What it means for most systems that they need to change a model based
on this:
CHECK DKIM PASS -- ACCEPT
CHECK RFC5322 BAD -- REJECT
BREAK
RESIGN
DISTRIBUTE
To this:
On Mon, 11 Oct 2010 23:05:13 +0100, Wietse Venema wie...@porcupine.org
wrote:
Charles Lindsey:
When the bad guy sends mail with (multiple) forged headers, the
best they can get is that naive mail programs render their forged
header with an indication that THE BAD GUY'S DKIM SIGNATURE
On 10/13/2010 2:27 PM, Jeff Macdonald wrote:
DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It should just provide an
identifier that can be verified. Instead of using the
On Wed, Oct 13, 2010 at 2:40 PM, Dave CROCKER d...@dcrocker.net wrote:
On 10/13/2010 2:27 PM, Jeff Macdonald wrote:
DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It
On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman
ietf-d...@kitterman.com wrote:
On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote:
And even if there was a DKIM signature, it is the BAD GUY'S signature,
which should cause it to go into the SPAM folder, with a large
phishing
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Jeff Macdonald
Sent: Wednesday, October 13, 2010 3:59 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
On Wed, Oct 13
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Wednesday, October 13, 2010 2:47 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
DKIM simply highlights an issue that's been there for a very
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Wednesday, October 13, 2010 1:59 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
I understand the issues
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote:
It strikes me that a DKIM verifier is already well into the business
of 2822 semantics as it knows about headers, header labels,
continuation syntax, header/body boundaries and so on.
In that light, taking an additional step wrt duplicate
In that light, taking an additional step wrt duplicate headers (or
malformed 2822 in general) is still in the same layer as the verifier.
My objection isn't so much layering within the software, because I know that
gets mushy real quick, but layering among the protocol specifications.
+1, well said Mark.
Its a real potential situation that is on par, IMTO, with what the
DKIM technology was suppose to help with. It was unfortunate it fell
through the cracks during the Threats Analysis RFC 5016 production. If
it was realized back then, I don't think anyone would be debating
On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote:
On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman
ietf-d...@kitterman.com wrote:
On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote:
And even if there was a DKIM signature, it is the BAD GUY'S signature,
which
On 10/13/2010 3:17 PM, John R. Levine wrote:
We put a bunch of stuff in DKIM to allow benign modifications of messages,
notably relaxed canoncalization. (We can argue about whether l= is
useful, but it's easy enough to ignore if one thinks it isn't.) I think
it's also reasonable to put
On 10/13/2010 4:59 PM, Mark Delany wrote:
I know we're not in the MUA business, but if DKIM makes no difference
to what an end-user finally sees, then it serves a very limited
purpose indeed.
Well, yes. But that's a /good/ thing, as a core capability.
More importantly, we are not in the
On 10/13/2010 8:56 PM, Mark Delany wrote:
If DKIM has any value it's that it ultimately affects the user mail
experience for the better. Consequently, to remain silent on matters
that we know will adversely affect that experience seems
contradictory. Similarly to not offer guidance to
What you are calling for would be good to have. It should be done.
Just not in the signing spec.
Correct me if I'm wrong, but I hear you saying that if one creates or
verifies the DKIM signature on a message, one should also do the double
header check somewhere in the mail processing path,
bill.ox...@cox.com wrote:
50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in
your example its the operator and how they determine reputation
Please read what was said.
No Signature, Double From --- Trapped/rejected by mipassoc.org
DKIM signed Double From
--On 12 October 2010 09:36:42 -0400 Hector Santos hsan...@isdg.net wrote:
No Signature, Double From --- Trapped/rejected by mipassoc.org
Really? You tested this? I assumed the message was accepted because it
contained a From: header belonging to a list member. Not because it was
On 10/12/2010 11:05 AM, Ian Eiloart wrote:
No Signature, Double From --- Trapped/rejected by mipassoc.org
Really? You tested this? I assumed the message was accepted because it
contained a From: header belonging to a list member. Not because it was
signed.
You are correct. The list
On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org
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
Charles Lindsey:
On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org
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)
Charles Lindsey:
When the bad guy sends mail with (multiple) forged headers, the
best they can get is that naive mail programs render their forged
header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED.
Sending forged headers with bad guy's DKIM signatures is not an
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Monday, October 11, 2010 3:18 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
It's not really an 'attack
Dave CROCKER wrote:
On 10/11/2010 3:05 PM, Wietse Venema wrote:
If you believe that sending mail with a valid bad guy signature is
an interesting attack on DKIM, then that implies that you're willing
to believe mail that is signed by arbitrary strangers.
Well...
But it's not an
50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in
your example its the operator and how they determine reputation
On Oct 11, 2010, at 9:23 PM, Hector Santos wrote:
Dave CROCKER wrote:
On 10/11/2010 3:05 PM, Wietse Venema wrote:
If you believe that sending mail with
John R. Levine wrote:
So here's a 0th cut at a list of headers where we should recommend
N+1 entries in the h=
rfc 5322
From
Sender
Reply-To (maybe not, since often smashed by mailing lists)
To
Cc(not Bcc even though it's 0/1)
Message-ID
Subject
I don't see incentives to spoof:
MIME-Version
Content-Type
What are the gains?
This has been discussed at great length. Please consult the list
archives.
R's,
John
___
NOTE WELL: This list operates according to
John R. Levine wrote:
I don't see incentives to spoof:
MIME-Version
Content-Type
What are the gains?
This has been discussed at great length. Please consult the list archives.
Thanks - you couldn't summarize or its too hard to explain?
I can search, certainly not consult. But
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
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 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,
-dkim] detecting header mutations after signing
We want to re-submit DKIM Signing to Proposed Standard, in order to fix
an edge condition that is only a theoretical issue and only fixes a
problem that is actually outside of the scope of what DKIM is trying
to achieve?
Detecting
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
1 - 100 of 110 matches
Mail list logo
