-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 10/14/2010 12:46 AM, Tony Hansen wrote:
Another potential option is to remove g= entirely:
I'd like to encourage our considering this strongly, for two reasons:
1. Pragmatic -- It's causing confusion and errors, while providing no
significant value-add.
2. Theoretical -- The feature
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input to
DKIM.
At the time DKIM was developed, worrying
On 10/14/2010 12:45 AM, SM wrote:
RFC 4871 discusses about DNS in various sections. Unfortunately,
there is no reference to the DNS specifications.
OMG. As in, wow.
I propose changing from:
section
title=Introduction
tDomainKeys Identified Mail (DKIM) permits a
Graham Murray wrote:
An MUA does not have to do filtering in order to support DKIM. It could
display the Authentication Results header, or take some action
depending
on whether there is a valid DKIM signature - in a similar way that some
web browsers will turn the URL bar green when the site
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
ask the question: Is it still worth changing that section into a WARNING
for
On 10/14/2010 9:05 AM, Tony Hansen wrote:
Is it still worth changing that section into a WARNING
for people upgrading from DomainKeys, saying to make darn sure that they
REMOVE g=; in their old DNS records because of interoperability issues?
So the question becomes: if we remove the
to:
section
title=Introduction
tDomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name xref
target=RFC1034 / with the message.
Another potential option is to remove g= entirely:
I'd like to encourage our considering this strongly, for two reasons:
I agree, g= seems to me to be a vestige of the confusion between i= and d=
identity.
If we do, it's probably a good idea to put in Tony's WARNING for people
upgrading
On Thu, Oct 14, 2010 at 8:09 AM, Dave CROCKER d...@dcrocker.net wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference
On 10/14/2010 9:49 AM, Mark Delany wrote:
Well, just to create a bit more of a rat-hole, is there any chance
you'd like to add a definitional link for the word message as well?
The easy and possibly sufficient answer is: RFC 5322.
If more precision is required, then Section 3.5 of RFC
It should be perfectly fine to say DKIM expects valid input, for
whatever definition of that we want to invent, and also state that
handing it anything else has either undefined results or specific bad
results.
We seem to be talking past each other here.
I don't see anyone proposing a
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
On 10/14/2010 10:17 AM, John R. Levine wrote:
I don't see anyone proposing a deep dive into 5322 validation. But 4871
already says you MUST sign the From: header. Why is that OK, but saying
you MUST NOT sign or validate something with two From: headers is not?
We're not suggesting anything
On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
Sent: Wednesday, October 13, 2010 9:12 AM
To: DKIM
Subject: Re:
What is essential is that it perform the task of validating and delivering a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is essential. Anything that can make this break needs
to
be covered, especially if there are ways to protect
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
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
What is essential is that it perform the task of validating and delivering
a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is essential. Anything that can make
Perhaps surprisingly, having redundant header fields does not make DKIM
break.
We must have some vastly different definition of break.
If allowing through modified messages that render very differently isn't
broken, shouldn't we remove the advice against signing with l=0? The
advice in
On 10/14/2010 07:58 AM, John R. Levine wrote:
Perhaps surprisingly, having redundant header fields does not make
DKIM break.
We must have some vastly different definition of break.
If allowing through modified messages that render very differently isn't
broken, shouldn't we remove the
SM wrote:
That text adds a requirement in an informative note.
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one existing need for a TXT record
and that is SPF and
agreed
On Oct 14, 2010, at 8:09 AM, Dave CROCKER wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 5:08 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] removing the g= definition?
On 10/14/2010 12:46 AM, Tony Hansen wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 5:10 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/13/2010 1:52 PM, Jim
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 5:23 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010
On 10/14/2010 07:56 AM, Mark Delany wrote:
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
What is essential is that it perform the task of validating and delivering a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is
-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 is not
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Thursday, October 14, 2010 7:38 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
On 10/14/2010 09:45 AM, John R. Levine wrote:
Unless there's *really* something they can't figure out without protocol
help, I'm not sure what the point of this is. This double added From thing
is trivial to detect with the current spec.
Well, yeah. That's why I don't understand why people
The difference is that the Subject:, To: and l= advice don't dabble in the
area of having to tell a DKIM implementer to enforce parts of other protocols.
Adding a second From: makes the message format illegal. The other ones don't.
We're still talking past each other. You're right, it
If you really think this is such a great big problem, maybe you should be
banging the drums at MAAWG or other venues where the correct set of ears
is potentially listening.
I would rather not have to run a session at MAAWG entitled How to fix the
security holes in DKIM, but I certainly could.
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Thursday, October 14, 2010 10:07 AM
To: Murray S. Kucherawy
Cc: DKIM List
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
Adding a second From: makes the message format
On 14/Oct/10 00:22, Jim Fenton wrote:
Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and
On 10/14/2010 10:15 AM, John R. Levine wrote:
If you really think this is such a great big problem, maybe you should be
banging the drums at MAAWG or other venues where the correct set of ears
is potentially listening.
I would rather not have to run a session at MAAWG entitled How to fix the
On 12/Oct/10 17:47, Barry Leiba wrote:
3) Philosophical conflictive parenthetical sentence:
(This can also be taken as a demonstration that DKIM is not designed
to support author validation.)
Yeh, that's the only part I agree on (though not with the reasoning
that follows). I'm
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John R. Levine
Sent: Thursday, October 14, 2010 10:15 AM
To: DKIM List
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
Am I
That makes it invalid input to any module that requires input to comply with
RFC5322, pure and simple.
Well, OK, with the stipulation that no existing MUA I have ever seen is
such a module.
I think if it becomes well-known that users of MUA 1 are easier to phish
than users of MUA 2, a lot
On 10/14/10 6:30 AM, Dave CROCKER wrote:
On 10/14/2010 9:05 AM, Tony Hansen wrote:
Is it still worth changing that section into a WARNING
for people upgrading from DomainKeys, saying to make darn sure that they
REMOVE g=; in their old DNS records because of interoperability issues?
So
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Thursday, October 14, 2010 10:45 AM
To: Murray S. Kucherawy
Cc: DKIM List
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
I think if it becomes well-known that users of
Not only do I want that, I did that. But the DKIM/ADSP module of that
system is purely DKIM/ADSP. The module that sits between the MTA and
the DKIM/ADSP module does the header count enforcement we're talking about,
knowing there's the potential for invalid mush in there.
Well, now we're
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,
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Thursday, October 14, 2010 10:50 AM
To: Murray S. Kucherawy
Cc: DKIM List
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
Well, now we're back to my question to Dave,
On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote:
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Thursday, October 14, 2010 10:45 AM
To: Murray S. Kucherawy
Cc: DKIM List
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
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
3) Philosophical conflictive parenthetical sentence:
(This can also be taken as a demonstration that DKIM is not designed
to support author validation.)
Yeh, that's the only part I agree on (though not with the reasoning
that follows). I'm ambivalent about having that
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and [RFC2047]. In particular, limitations on the number of
occurrences of particular header fields specified in
+1 on removing g=.
Barry, as participant
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one existing need for a TXT
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen t...@att.com wrote:
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
ask the
On 10/14/2010 11:54 AM, Barry Leiba wrote:
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansent...@att.com wrote:
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons
Barry Leiba barryle...@computer.org wrote:
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those
Barry Leiba wrote:
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one
Scott Kitterman wrote:
+1.
Just as a note of clarification, SPF doesn't prefix TXT records, but I don't
think that affects the analysis.
The Network Solutions DNS Records manager does not allow you to add a
TXT record without a sub-domain, so to add one, you have to add *
which when
Barry Leiba wrote:
On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote:
At 17:31 13-10-10, Hector Santos wrote:
My proposal to add more informative notes to help minimize this for
the systems with the lack of DNS admin expertise on board. In
particular for those with currently one
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input
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
Barry, there are crossing questions.
This question came up in response to removing 3.6.1.1 totally separate
from the question of removing g= altogether.
If we remove 3.6.1.1 without removing g= altogether, the question below
becomes pertinent.
If we remove g= altogether, then we can remove
Well, now we're back to my question to Dave, what's the advantage of
leaving that as folklore rather than putting it in the spec other than the
warm theological feeling of somewhat preserving layer distinctions, except
for all the places we already didn't?
Why does it have to be normative?
No, that doesn't solve the problem for all of the implementations
that are out there now that implement 4871. Removing g= is only going
to make the situation even worse because you've now taken away the
documentation.
I wouldn't be opposed to moving it to an appendix of deprecated features,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 3:33 PM
To: Tony Hansen
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
Although
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John R. Levine
Sent: Thursday, October 14, 2010 3:31 PM
To: Barry Leiba
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
No, that
On 10/14/10 3:30 PM, John R. Levine wrote:
No, that doesn't solve the problem for all of the implementations
that are out there now that implement 4871. Removing g= is only going
to make the situation even worse because you've now taken away the
documentation.
I wouldn't be opposed to
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Isn't that what the IANA registry is there to prevent?
I dunno. What does IANA do in cases like these?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for
On Oct 14, 2010, at 4:44 PM, John R. Levine wrote:
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Isn't that what the IANA registry is there to prevent?
I dunno. What does IANA do in cases like these?
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Thursday, October 14, 2010 5:00 PM
To: DKIM List
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
This is a small 2 days collection break down of the signed mail coming in:
- total msgs :67028
- dkim_sign : 1779 (2.7% signed)
- dkim_pass : 89.9%
- dkim_fail : 10.1%
--25.9% : dkim_body_hash_mismatch
--14.0% : dkim_signature_bad
--37.6% :
On 10/14/2010 6:30 PM, John R. Levine wrote:
I wouldn't be opposed to moving it to an appendix of deprecated features,
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Since this particular feature is apparently used in about .0007%
Hi JD,
At 12:24 14-10-10, J.D. Falk wrote:
We've done a surprisingly good job of getting the word out that DK
is over and DKIM is the future.
We're doing a heck of a job. :-)
There is still some confusion between DomainKeys and DKIM. I still
see people signing with DomainKeys. You can pick
70 matches
Mail list logo
