Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 12:56 AM, Steve Atkins wrote:
On Aug 2, 2010, at 3:37 PM, Rolf E. Sonneveld wrote:
Hi, all
in the light of the discussion about draft-ietf-dkim-mailinglists I'd
like to propose an alternative way to solve the MLM dilemma on how to
deal with original DKIM signature/message versus sending out a modified
version of the message. This proposal may be impractical or hard to
realize, but I'd just thought I had to share it with you.
The proposal is to preserve the original message + DKIM signature and to
add the new (probably partially rewritten) output message, combined into
a multipart/alternative structure. The combined message is sent by the
MLM to the recipient. For the original message + DKIM signature, we
could register a Content-Type of e.g. message/dkim-original-message with
IANA. The output message would be the other part of the
multipart/alternative, with the normal MIME structure of the MLM output
message. A sample message sent by an MLM (or more in general, by a
re-signer) would look like:
Does this mean that anyone can take their own content and
a message DKIM signed by someone else, and then send it out
such that their content will be displayed, but the (non-displayed)
signed message will be checked?
No, it means that for both message parts a DKIM signature is checked for
presence and the results of both are made available to the receiver
('receiver' as in Murrays draft defined in par. 3.1). So effectively it
means that in the situation you described, the 'own content' is
displayed but lacks a verified DKIM signature and as such should be
treated as a message without DKIM signature. The proposal just means to
provide a way to tunnel the original contents of a message + DKIM
signature and enable the verifier to verify not only the DKIM signature
provided by the resigner, but also the original DKIM signature as well.
The A-R results of the original DKIM signature, provided by the resigner
as part of the new DKIM signature can only be trusted if the
verifier/receiver trusts the resigner. With the original DKIM signature
+ message present, there is no need for this trust relation; the
verifier itself can verify.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:36 AM, John Levine wrote: The proposal is to preserve the original message + DKIM signature and to add the new (probably partially rewritten) output message, combined into a multipart/alternative structure. The combined message is sent by the MLM to the recipient. Once again, I can only see this as screwing up the 99+% of users for whom the lists work just fine for the1% who consider themselves so important that they need to mark their list mail with ADSP. I did not have ADSP in mind when writing this proposal. Let me be clear about ADSP: IMO domains that publish adsp=discardable and yet send mail with that domain via mailing lists, get what they deserve: problems. Imagine you're a list manager. Your list has 1000 subscribers. Two of them demand that you do something to prevent address forgery due to forged unsigned messages, a problem that you have never observed to happen on your lists. What do you do? I know what I'd do. In a nutshell the problem of the combination DKIM + MLM can be summarized (and simplified) as follows. On the plus side: 1. the mail that is received by a subscriber to a mailing list carries (most of the time) the original From. 2. the original DKIM signature can still be present in the message (if we recommend the MLM authors to not remove DKIM-Signatures) However... 3. the MLM rewrites the Subject (in many cases) 4. the MLM adds a footer (many cases) 5. see par. 3.3 of Murrays draft for more things MLMs do to messages That means, we have a signature + From, but we no longer have a reliable copy of the message to verify them. 6. we can tell the MLM authors to change their code to no longer do 3., 4. and 5. but, as Murray describes in par. 3.4: quote However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. /quote With this situation in mind, I wrote my proposal, to provide the verifier on the receiving side with a means to verify the original DKIM signature. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
--On 29 July 2010 20:53:40 +0200 J.D. Falk jdfalk-li...@cybernothing.org wrote: On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: --On 26 July 2010 18:24:34 +0200 J.D. Falk jdfalk-li...@cybernothing.org wrote: I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end. With ADSP, if your end is broken then you can still talk SMTP and even sign with DKIM, but the other end may silently discard your message. There's no feedback. About 90% of the email sent to my personal email address ends up in a Gmail junk mail folder, that I never check. There's no feedback there, either. As far as SMTP is concerned, that mail was successfully delivered. huh? The complaint is that the message is silently discarded somewhere downstream, and the sender gets no feedback. How can it matter what the technical means of achieving this are? -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Rolf,
It seems much easier for MLS (Mail List Servers) to preempt
restrictive ADSP Domains from subscribing and from submitting mail to
the list enabled with DKIM resigning.
Follow the specification and apply it accordingly using engineering
sense. No Subjective concepts. We need persistent expectations across
the board. The problem here is that list managers what to sign
everything with disregard to policy. There is no way you going to get
DKIM+POLICY+MLS
correct. Something has to give. Support policy is an answer, getting
rid of it is another so that at least everyone can work under the same
plane.
It would easy to add new common sense options to our list server such:
List DKIM/ADSP options:
[X] DKIM Sign this list
[CLICK FOR DKIM SIGNING OPTIONS]
[X] Disallow ADSP DISCARDABLE domains from subscribing.
[X] Disallow ADSP DISCARDABLE domain list submissions.
[X] Send Notification to domain for ADSP=DISCARD Policy
restricted subscription or submissions.
[EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE]
[EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE]
The template #1 would probably say:
Dear {MSG.FROM}
Sorry, but you can not subscribe to this list using
a restricted ADSP DKIM=DISCARDABLE policy for your
domain. If we had accept your subscription, there is
risk of harming the subscription status of other members
already on the list. We don't wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and reapply to subscribe
to the list.
2) Use another domain that isn't ADSP restricted.
The template #2 would probably say:
Dear {MSG.FROM}
Sorry, message submission to this list is restricted to
domains with non-ADSP DISCARDABLE policies only.
If we had accepted it, there is risk of harming the
subscription status of other members of the list. We don't
wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and resubmit your message.
2) Use another domain that isn't ADSP restricted.
I can't remove popular features even if I wanted to and I seriously
doubt any RFC will change this for most systems:
[X] Add [LIST] Tag to Subject Line
[X] Add Footer [EDIT FOOTER TEMPLE]
[X] Set Reply-To to List address
[_] Strip HTML
[_] Strip Attachments
and all other inherent integrity breaking ideas in MLS software and
used by MLM (Mail List Managers).
We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into
DKIM/POLICY. -1 towards ideas of altering 5322.From lines which will
only open a nasty can of worms. We would be breaking all kinds of
Authorship From expectations, including touching base with copyright
related issues.
Or get rid of POLICY if its hurting DKIM implementation for list
servers. Working it to standardization yet list managers with DKIM
resigners intentionally ignoring it is not going to work very well.
Not supporting it is one thing, yet allowing ADSP domains to submit
mail is another thing. It doesn't mix well.
If this becomes the behavior what will happen is SMTP systems will be
force to accept mail to discard it. They won't be be able to reject
mail at the transport level because that will promote a bounce towards
the list server and this will hurt members of the list.
We can't dictate to SMTP developer and operators not to employ session
level rejections.
--
HLS
Rolf E. Sonneveld wrote:
On 08/03/2010 02:36 AM, John Levine wrote:
The proposal is to preserve the original message + DKIM signature and to
add the new (probably partially rewritten) output message, combined into
a multipart/alternative structure. The combined message is sent by the
MLM to the recipient.
Once again, I can only see this as screwing up the 99+% of users for
whom the lists work just fine for the1% who consider themselves so
important that they need to mark their list mail with ADSP.
I did not have ADSP in mind when writing this proposal. Let me be clear
about ADSP: IMO domains that publish adsp=discardable and yet send mail
with that domain via mailing lists, get what they deserve: problems.
Imagine you're a list manager. Your list has 1000 subscribers. Two
of them demand that you do something to prevent address forgery due to
forged unsigned messages, a problem that you have never observed to
happen on your lists. What do you do? I know what I'd do.
In a nutshell the problem of the combination DKIM + MLM can be
summarized (and simplified) as follows.
On the plus side:
1. the mail that is received by a subscriber to a mailing list carries
(most of the time) the original From.
2. the original DKIM signature can still be present in the message (if
we recommend the MLM authors to not remove DKIM-Signatures)
However...
3. the MLM rewrites the Subject (in many cases)
4. the
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:02 PM, Hector Santos wrote:
Rolf,
It seems much easier for MLS (Mail List Servers) to preempt
restrictive ADSP Domains from subscribing and from submitting mail to
the list enabled with DKIM resigning.
Follow the specification and apply it accordingly using engineering
sense. No Subjective concepts. We need persistent expectations across
the board. The problem here is that list managers what to sign
everything with disregard to policy. There is no way you going to get
DKIM+POLICY+MLS
correct. Something has to give. Support policy is an answer, getting
rid of it is another so that at least everyone can work under the same
plane.
It would easy to add new common sense options to our list server such:
List DKIM/ADSP options:
[X] DKIM Sign this list
[CLICK FOR DKIM SIGNING OPTIONS]
[X] Disallow ADSP DISCARDABLE domains from subscribing.
[X] Disallow ADSP DISCARDABLE domain list submissions.
[X] Send Notification to domain for ADSP=DISCARD Policy
restricted subscription or submissions.
[EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE]
[EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE]
The template #1 would probably say:
Dear {MSG.FROM}
Sorry, but you can not subscribe to this list using
a restricted ADSP DKIM=DISCARDABLE policy for your
domain. If we had accept your subscription, there is
risk of harming the subscription status of other members
already on the list. We don't wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and reapply to subscribe
to the list.
2) Use another domain that isn't ADSP restricted.
The template #2 would probably say:
Dear {MSG.FROM}
Sorry, message submission to this list is restricted to
domains with non-ADSP DISCARDABLE policies only.
If we had accepted it, there is risk of harming the
subscription status of other members of the list. We don't
wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and resubmit your message.
2) Use another domain that isn't ADSP restricted.
I can't remove popular features even if I wanted to and I seriously
doubt any RFC will change this for most systems:
[X] Add [LIST] Tag to Subject Line
[X] Add Footer [EDIT FOOTER TEMPLE]
[X] Set Reply-To to List address
[_] Strip HTML
[_] Strip Attachments
and all other inherent integrity breaking ideas in MLS software and
used by MLM (Mail List Managers).
We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into
DKIM/POLICY. -1 towards ideas of altering 5322.From lines which will
only open a nasty can of worms. We would be breaking all kinds of
Authorship From expectations, including touching base with copyright
related issues.
Or get rid of POLICY if its hurting DKIM implementation for list
servers. Working it to standardization yet list managers with DKIM
resigners intentionally ignoring it is not going to work very well.
Not supporting it is one thing, yet allowing ADSP domains to submit
mail is another thing. It doesn't mix well.
If this becomes the behavior what will happen is SMTP systems will be
force to accept mail to discard it. They won't be be able to reject
mail at the transport level because that will promote a bounce towards
the list server and this will hurt members of the list.
We can't dictate to SMTP developer and operators not to employ session
level rejections.
My proposal was and is _not_ aimed at ADSP and _not_ at policies in
general. The proposal only identifies a means to make MLMs (and
re-signers in general) in a way 'transparant' for receivers of a mail.
Nothing more, nothing less.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator. If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that etf-d...@mipassoc.org is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution. thanks, now back into lurk mode Bill On Aug 3, 2010, at 6:03 AM, Rolf E. Sonneveld wrote: On 08/03/2010 02:36 AM, John Levine wrote: The proposal is to preserve the original message + DKIM signature and to add the new (probably partially rewritten) output message, combined into a multipart/alternative structure. The combined message is sent by the MLM to the recipient. Once again, I can only see this as screwing up the 99+% of users for whom the lists work just fine for the1% who consider themselves so important that they need to mark their list mail with ADSP. I did not have ADSP in mind when writing this proposal. Let me be clear about ADSP: IMO domains that publish adsp=discardable and yet send mail with that domain via mailing lists, get what they deserve: problems. Imagine you're a list manager. Your list has 1000 subscribers. Two of them demand that you do something to prevent address forgery due to forged unsigned messages, a problem that you have never observed to happen on your lists. What do you do? I know what I'd do. In a nutshell the problem of the combination DKIM + MLM can be summarized (and simplified) as follows. On the plus side: 1. the mail that is received by a subscriber to a mailing list carries (most of the time) the original From. 2. the original DKIM signature can still be present in the message (if we recommend the MLM authors to not remove DKIM-Signatures) However... 3. the MLM rewrites the Subject (in many cases) 4. the MLM adds a footer (many cases) 5. see par. 3.3 of Murrays draft for more things MLMs do to messages That means, we have a signature + From, but we no longer have a reliable copy of the message to verify them. 6. we can tell the MLM authors to change their code to no longer do 3., 4. and 5. but, as Murray describes in par. 3.4: quote However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. /quote With this situation in mind, I wrote my proposal, to provide the verifier on the receiving side with a means to verify the original DKIM signature. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:13 PM, bill.ox...@cox.com wrote: When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator. Again, I am not talking about ADSP. If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that etf-d...@mipassoc.org is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution. thanks, now back into lurk mode Trusting the MLM may be possible for you personnly for this particular mailing list, but your choice is not scaleable to the Internet at large. Or is the general consensus that (in the long run) the reputation of the MLM domain is sufficient for the verifier/receiver of MLM distributed mail? I don't read that in the draft. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On Tuesday, August 03, 2010 08:02:34 am Hector Santos wrote: It seems much easier for MLS (Mail List Servers) to preempt restrictive ADSP Domains from subscribing and from submitting mail to the list enabled with DKIM resigning. This would also give you the use case to deal with of restrictive ADSP published after someone has already subscribed. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 03:03 AM, Rolf E. Sonneveld wrote: With this situation in mind, I wrote my proposal, to provide the verifier on the receiving side with a means to verify the original DKIM signature. Rolf, When we wrote our dkim implementation, we did a bunch of work within the existing DKIM framework (using l= and z=) that allowed us to get most original signatures to reverify through mailing lists (~95%). No work needed on the mailing list software at all. What you're proposing would be close to 100% reverify rate of the lists that choose to implement what you're proposing. Right now that's 100% * 0% :) But even if it was accepted and caught on, it would still be a *very* long time before you got to anywhere close to what we achieved. Maybe this would be good for the pathological cases, but it probably wouldn't be good enough to trust for, say, ADSP-discardable or any other indicator/service that said that you should treat unsigned/broken signatures harshly. I guess the meta question here is what the purpose is you have in mind. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
I trust the reputation and blame the reputation of the MLM as a single standalone author. I have no interest in the contributors reputation. As a receiver who is on many lists I unsubscribe when the list no longer meets my viewing needs. As a admin of mail systems I dont want to interrupt that flow unless virus or spam is egregious On Aug 3, 2010, at 9:30 AM, Rolf E. Sonneveld wrote: On 08/03/2010 02:13 PM, bill.ox...@cox.com wrote: When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator. Again, I am not talking about ADSP. If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that etf-d...@mipassoc.org is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution. thanks, now back into lurk mode Trusting the MLM may be possible for you personnly for this particular mailing list, but your choice is not scaleable to the Internet at large. Or is the general consensus that (in the long run) the reputation of the MLM domain is sufficient for the verifier/receiver of MLM distributed mail? I don't read that in the draft. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Trusting the MLM may be possible for you personnly for this particular mailing list, but your choice is not scaleable to the Internet at large. Or is the general consensus that (in the long run) the reputation of the MLM domain is sufficient for the verifier/receiver of MLM distributed mail? I don't read that in the draft. How do you sort list mail now? By List-id, or by individual From lines? Everyone I know sorts by the list. In a few cases I do bozo filtering to dump individual messages, but that's on genuine mail from bozos, so signatures aren't an issue. If people expect mail recipients to stop treating a list as a single mail stream and instead as unrelated messages from the contributors, it'd be helpful if they explained why 30 years of practice is going out the window. To me this looks very much like the drunk searching for his keys under the streetlight. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld Sent: Tuesday, August 03, 2010 6:30 AM To: Bill Oxley @ Cox Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature Or is the general consensus that (in the long run) the reputation of the MLM domain is sufficient for the verifier/receiver of MLM distributed mail? I don't read that in the draft. That's definitely my forward-looking view, but it's hard to include text in a document that points to something in the future with any degree of certainty. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Tuesday, August 03, 2010 7:59 AM To: Rolf E. Sonneveld Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature When we wrote our dkim implementation, we did a bunch of work within the existing DKIM framework (using l= and z=) that allowed us to get most original signatures to reverify through mailing lists (~95%). No work needed on the mailing list software at all. But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 09:15 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Tuesday, August 03, 2010 7:59 AM To: Rolf E. Sonneveld Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature When we wrote our dkim implementation, we did a bunch of work within the existing DKIM framework (using l= and z=) that allowed us to get most original signatures to reverify through mailing lists (~95%). No work needed on the mailing list software at all. But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, August 03, 2010 9:21 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. I guess I don't either. You're saying use of l= and z= got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says Copied header field values are for diagnostic use which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a z= tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., This signature failed, and via the 'z=' we know why... but it still failed.). -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 09:40 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, August 03, 2010 9:21 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. I guess I don't either. You're saying use of l= and z= got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says Copied header field values are for diagnostic use which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a z= tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., This signature failed, and via the 'z=' we know why... but it still failed.). Yeah, well, sue me for flipping that MUST NOT the bird. It works, z= is signed by the originator, and it's probably as high a recovery rate that you'll ever get going through mailing lists. We weren't proposing that it be part of any standard, and our reasons had nothing to do with ADSP either. All I'm saying is that if you want mailing list signature recovery, we've already done that and wrung out about as much as can be hoped for. As I asked earlier, what is the purpose of this anyway? We were doing it to deal with spear-phishing attacks. Maybe I've missed the motivation for the mime thingy. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 06:53 PM, Michael Thomas wrote: On 08/03/2010 09:40 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, August 03, 2010 9:21 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. I guess I don't either. You're saying use of l= and z= got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says Copied header field values are for diagnostic use which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a z= tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., This signature failed, and via the 'z=' we know why... but it still failed.). Yeah, well, sue me for flipping that MUST NOT the bird. It works, z= is signed by the originator, and it's probably as high a recovery rate that you'll ever get going through mailing lists. We weren't proposing that it be part of any standard, and our reasons had nothing to do with ADSP either. All I'm saying is that if you want mailing list signature recovery, we've already done that and wrung out about as much as can be hoped for. As I asked earlier, what is the purpose of this anyway? We were doing it to deal with spear-phishing attacks. Maybe I've missed the motivation for the mime thingy. The motivation was the MLM draft document, par. 3.4. I quote: quote Changes that merely add new header fields, such as those specified by [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to a DKIM-participating email infrastructure in that their addition by an MLM will not affect any existing DKIM signatures unless those fields were already present and covered by a signature’s hash or a signature was created specifically to disallow their addition (see the note about h= in Section 3.5 of [DKIM]). The shortest path to success for DKIM would be to mandate that all MLM software be redesigned or re-configured with that goal in mind. However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire entire message. Thus, the following sections also investigate and recommend other processing alternatives. /quote It was my intention to add one such 'processing alternative'. Now the question is: does it cover the remaining 5% or not? And if so (if we could get to 100%), is it worth the (huge) effort to rewrite DKIM? /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 06:40 PM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, August 03, 2010 9:21 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. I guess I don't either. You're saying use of l= and z= got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says Copied header field values are for diagnostic use which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a z= tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., This signature failed, and via the 'z=' we know why... but it still failed.). Furthermore, the use of l= is discouraged in RFC4871 and in the MLM draft: par. 3.5: quote INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might allow display of fraudulent content without appropriate warning to end users. The l= tag is intended for increasing signature robustness when sending to mailing lists that both modify their content and do not sign their messages. However, using the l= tag enables attacks in which an intermediary with malicious intent modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. Examples are described in Security Considerations (Section 8 http://tools.ietf.org/html/rfc4871#section-8). To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length. /quote and quote A possible mitigation to this incompatibility is use of the l= tag to bound the portion of the body covered by the body hash, but this not workable for [MIME] messages and moreover has security considerations (see Section 3.5 of [DKIM]). Its use is therefore discouraged. /quote /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 10:34 AM, Rolf E. Sonneveld wrote: quote Changes that merely add new header fields, such as those specified by [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to a DKIM-participating email infrastructure in that their addition by an MLM will not affect any existing DKIM signatures unless those fields were already present and covered by a signature’s hash or a signature was created specifically to disallow their addition (see the note about h= in Section 3.5 of [DKIM]). The shortest path to success for DKIM would be to mandate that all MLM software be redesigned or re-configured with that goal in mind. However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire entire message. Thus, the following sections also investigate and recommend other processing alternatives. /quote That's not really answering my question, unfortunately. I'm asking what you intend to use the original signature's verification status for with the knowledge that you will have a non-zero false positive rate. We did our experiment with spear-phishing in mind: ie, can we tag mail purporting to originate from us with a bad/missing signature with an acceptable false positive rate. It was pretty close. I don't know what problem your proposal is intending to solve. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
