Subject: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME?

From: Claudio Allocchio <[email-masked]>
Date: Sun, 11 Jan 2015 16:06:19 +0100 (CET)

Hello all,

I've been explicitly asked the question if the correct way to avoind the 
possible forgery of DSNs described in the Security Consideration sections 
of RFC3464 is to have the MTA sending S/MIME signed receipts instead of 
plain MIME/Multipart...

Well, in theory that's the correct answer, and it looks more an 
implementation/support problem of MTAs than realted to protool 
specifications... it is just combining two specifcations to get the 
desidered result IMHO... and veryfying that there are s/w implementation 
which allow the administrator to do that... but better ask a wider opinion 
before answering...

Comments?

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Ned Freed <[email-masked]>
Date: Sun, 11 Jan 2015 07:11:49 -0800 (PST)

> which allow the administrator to do that... but better ask a wider opinion

What mechanism are you supposed to use to validate the signature on such
receipts? Absent a specification for such a mechanism - which as far as I know
does not exist - I don't see how this really helps.

The other question is what sort of forgery are you worried about? If you're
talking about spam DSNs, then that can be dealt with by correlating DSNs with
the messages a user actually sent.

If, OTOH, you're worried about someone sending fake DSNs saying a message
was bounced when it wasn't, or received when it wasn't, then I think a better
understanding of the actual threat you're concerned with is needed before
suggestions can be made.

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 11 Jan 2015 16:48:11 +0100 (CET)

Hi Ned,

> does not exist - I don't see how this really helps.

I was thinking of a server-certificate issued to the MTA making the 
signature, and to use the certificate to sign with S/MIME the DSN message. 
So... is it not enough to use the same signiature verification mechanisms 
used when a human user send an S/MIME signed message? Or am I wrong?

> the messages a user actually sent.

no, this was not the case.

> understanding of the actual threat you're concerned with is needed before

This was the case being asked indeed... the latter:

- a message is sent asking for a DSN.

- the message indeed is NOT delivered to the actual recipient (for example 
it is intercepted by somebody else via spoofed DNS MX records, or other 
DNS spoofing mechanisms), but the man-in-the-middle MTA issues a forged 
positive DSN to the sender.

- the sender is convinced his message was delivered, but indeed it was 
not.

In such a case, of case, there is of course the verification inside the 
MTA log of the real recipient which can identify the forgery, but the 
sender usually does not have access to this information, and trusts what 
the DSN he/she received say.

(the other case, e.g. the message was delivered, but a forged negative DSN 
is issued, is not a real issue in such a case).

Does this clarify the issue?

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 11 Jan 2015 16:57:36 +0100 (CET)

in short... the question may be seen as:

how can the sender be sure that the DSN he/she receives (when he/she ask 
one sending a message) really comes from the real recipient MTA, thus the 
message was really delivered?

I'm talking about an average end user, with not idea of internals... of 
course, and of the current deployment, so Secure DNS is "not yet there" in 
many environments.

On Sun, 11 Jan 2015, Claudio Allocchio wrote:

> - the message indeed is NOT delivered to the actual recipient (for example it 
> is intercepted by somebody else via spoofed DNS MX records, or other DNS 
> spoofing mechanisms), but the man-in-the-middle MTA issues a forged positive 
> DSN to the sender.
>
> - the sender is convinced his message was delivered, but indeed it was not.
>
> In such a case, of case, there is of course the verification inside the MTA 
> log of the real recipient which can identify the forgery, but the sender 
> usually does not have access to this information, and trusts what the DSN 
> he/she received say.
>
> (the other case, e.g. the message was delivered, but a forged negative DSN is 
> issued, is not a real issue in such a case).
>

---

From: Ned Freed <[email-masked]>
Date: Sun, 11 Jan 2015 08:45:41 -0800 (PST)

> used when a human user send an S/MIME signed message? Or am I wrong?

OK, so I have a proper server certificate with a proper chain of trust in
place. How do you know that that certificate is authorized to sign DSNs for a
given recipient address?

If your response is to say that the domain in the certificate and the domain of
the recipient address must match, that's not going to work because mail servers
routinely handle hundreds, thousands, even tens of thousands of recipient
domains.

> positive DSN to the sender.

If you're talking about general Internet mail, why bother with the forgery of a
success DSN? The chances of success DSNs working in today's Internet are low -
they create far too much blowback spam.

And if you're in a position to mandate support for and generation of success
DSNs by your recipients, you're also in a position to mandate the use of a
particular certificate for signing those DSNs, and your problem is solved -
sort of. I also note that you'd probably also be in a position to mandate the
use of secure DNS, server certificate validation, and so on, eliminating the
ability to intercept the mail in the first place.

But this has now shifted into the area of bilateral agreements, not Internet
email in general, and I no longer see it as having much relevance to the IETF,
whose responsibility is to create solutions that operate at true Internet
scale.

> Does this clarify the issue?

The reason I said "sort of" is while you may have mitigated the ability of an
intermediary to intercept mail and lie about it having been delivered, you
still do not have true nonrepudication of delivery, which it seems to me is
what you're really after. Specifically, you're still trusting some other set of
administrative domains - the domains receiving these messages, not to lie their
little asses off.

The solution to this is to use a trusted third party, and I were implementing
something like this this is the approach I'd use. There are various commercial
offerings that provide various sorts of funcitonality in thie general area. The
one I know for sure has an offering in this area is RPost, but I think Cisco
also has something.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 11 Jan 2015 22:19:07 +0100

IMNSHO:

The proper way for a sender is to use an ENVID containing a rich dose of 
entropy, for a DSN generator to quote ENVID in all DSNs, and for a DSN 
parser to check ENVID and be appropriately distrustful if not supplied.

These behaviour changes are cheap and simple to implement, require no 
semantic or syntactical changes, and harm compatbility with nothing.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2015 21:54:28 -0000

>message was really delivered?

That's easy: you can't, but it doesn't matter.  As as too often the
case, the security considerations section of 3464 didn't consider the
realities of the modern Internet.

Since most DSNs are real responses to fake spam, most of the work is
picking out the DSNs that are responses to real messages.  Mailing
list software spends enormous effort on heuristics to do this, which
boil down to looking for some distinctive characteristic of the real
mail you send in the message enclosed in the bounce.

Next, you have no idea where a message might legitimately go.  Most
mail services handle mail for anywhere from dozens to tens of
thousands of domains, and mail is routinely forwarded from one system
to another, e.g. mail to [email-masked] goes to me, so a DSN would
come from my host miucha.iecc.com.  In fact, anyone with access to a
copy of a message can provoke a 100% genuine DSN merely by remailing
it to a bad address.  It is common for a message to be both delivered
and forwarded, so if you get a DSN, it's quite possible that the
message was also delivered successfully somewhere else.

As Ned noted, there is no way to tell what MTA is supposed to be
sending DSNs for what mail domains.  My tiny system handles mail for a
couple of dozen domains, none of which have any obvious connection to
me other than the MX records.  It is not rare for a system to handle
mail for a domain and not know it, e.g., someone stops paying for
hosted mail, but doesn't change the MX.  In that case, the DSN would
say something like "not an open relay" or "use your own mail system".

Fortunately, fake DSNs have never been a problem other than the ones
from spam bounce storms, which don't seem to be what you're asking
about.  What problem are we supposed to solve here?

R's,
John

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 11 Jan 2015 23:40:55 +0100 (CET)

> about.  What problem are we supposed to solve here?

As Ned pointed out, in a "regulated (virtual) organisation" you can impose 
further administrative rules to solve most of the problems you correctly 
describe above... and this can also have quite strong implications leading 
to nearly (or completely) "legally valid" DSNs with strong value. My guess 
is that the question which came to me came with in mind such a regulated 
environment, whaere you can fix many things... and also the services with 
a third party notary service which exists prove this can be done.

... but I just tried to extend the question of "(positive) DSNs non 
repudiation" to the open Internet, trying to see if we have, if any, 
possible mechanisms to do so, without enforcing additional rules which you 
can apply only within a closed regulated environment.

It is true... RFC3464 Security Consideration sections is quite in line 
with "ha ok... I also have to write this bothering security sections, 
let's write something....", thus useless in real life... but for example 
the idea of forcing also the ENVID request may be interesting (I've not 
yet tried to examin it in full detuils, but maybe Arne can provide a 
quicker transaction schema to explain it).

Another consideration: even if a mail server handles thousands of domains, 
it is true that a sender can get a list of mail server associated to any 
domain (A, AAAA, or MX rcords) and just check that the DSN comes with a 
valid certificate of one of them.

It is also true that "forwarding" is common practice (my Gmail address 
just forwards to my official address... sorry Google... no indexing on my 
messages), but if the mail server associated to the domain the message is 
sent supports correctly DSNs, for the sender it does not matter if a 
message is then forwarded somewhere else: I asked a deliery to THAT 
mailbox, and indeed it reached it... if the message then is forwarded 
elsewhere and get lost... it is the mailbox owner fault... if he did not 
received it... as the message was officially delivered where it was 
suppoused to go.

So, the problems I'm trying to solve (or to see if there is workable 
solution) is a resonable non-repudiation mechanism for DSNs in the open 
Internet using existing specifications, without imposing additional rules 
which only a closed regulated environment can force. This is of course a 
wider topic that the one which came to me from some users... but as said, 
their "virtual organisation problem" can be solved imposing some rules and 
restrictions... and thus it is not so interesting.

It may be that we just cannot have a "reasonable" solution for the real 
open Internet... but as I'm not sure and a solution may exist, I started 
this (sunday) brainstorming...

:-)

all the best!

---

From: "John R Levine" <[email-masked]>
Date: 11 Jan 2015 18:12:25 -0500

> describe above... and this can also have quite strong implications leading to 
> nearly (or completely) "legally valid" DSNs with strong value.

Oh, sure.  Within a private system with its own rules, you can do this 
easily.  Delivery reports within a single Exchange server are quite 
reliable, for example.

> Another consideration: even if a mail server handles thousands of domains, it 
> is true that a sender can get a list of mail server associated to any domain 
> (A, AAAA, or MX rcords) and just check that the DSN comes with a valid 
> certificate of one of them.

Nope.  Mail servers have no idea what name you used to find them, and it 
is very common for inbound and outbound mail servers to be different.  My 
inbound mail server is mail1.iecc.com, but bounces come from 
miucha.iecc.com.  For hosted mail, it's common for customers to use MXes 
in their own domain that point to the host's mail server.  Or see the MX 
for my client quarteracre.net.

> indeed it reached it... if the message then is forwarded elsewhere and get 
> lost... it is the mailbox owner fault... if he did not received it... as the 
> message was officially delivered where it was supposed to go.

This seems contrary to your previous question about whether a 
non-technical user could tell if her message was delivered successfully.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 12 Jan 2015 00:34:25 +0100 (CET)

> Nope.  Mail servers have no idea what name you used to find them, and it is 
> very common for inbound and outbound mail servers to be different.  My 
> inbound mail server is mail1.iecc.com, but bounces come from miucha.iecc.com. 
> For hosted mail, it's common for customers to use MXes in their own domain 
> that point to the host's mail server.  Or see the MX for my client 
> quarteracre.net.

yes, you are right !

>> lost... it is the mailbox owner fault... if he did not received it... as 
>> the message was officially delivered where it was supposed to go.
>
> This seems contrary to your previous question about whether a non-technical 
> user could tell if her message was delivered successfully.

it was a different consideration indeed :-)  I was considering the case 
where a non technical user send for example a message to me at 
[email-masked] (which is a valid mailbox I have), and asks 
for a DSN. The mail server @eletra.eu delivers a positive DSN, but then 
also forwards the message to me at my real common mailbox @garr.it. The 
sender knows that the message was delivered to my mailbox @elettra.eu, and 
this is enough for her because it arrived to the mailbox she intended to 
reach... if then the forward makes the message disapper in a black hole, 
it is MY fault... and it is the same situation which happens If I press 
"delete" on a new message before reading it, if you think to the 
heuristic...  like if I get a snail mail in the mailbox, open the mailbox, 
and the wind blows away the letter when I'm taking it into the house. :-) 
(it may indeed happen here in Trieste where 90mph or more gusts are quite 
common in winter...)

best!

---

From: "John R Levine" <[email-masked]>
Date: 11 Jan 2015 20:25:24 -0500

> it was a different consideration indeed :-) ...
> knows that the message was delivered to my mailbox @elettra.eu, and this is 
> enough for her because it arrived to the mailbox she intended to reach... if 
> then the forward makes the message disapper in a black hole, it is MY 
> fault...

I dunno about the people you know, but the ones I know wouldn't find that 
to be a very interesting distinction.  It's not like mail blowing out of 
your mailbox, because that only affects a few letters, while a screwed up 
forward will lose all of them.

The DSN extensions in RFC 3461 are intended to make this all work.  The 
ORCPT and ENVID parameters let you link the DSN from a forwarded message 
to the original message.  Sendmail and Postfix have some support for the 
DSN extension, but it's not clear to me how complete it is (notably, 
whether they pass ENVID and ORCPT on forwarded mail) and how many people 
actually turn it on.

Regards,

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 Jan 2015 09:36:33 +0100

On Sunday, January 11, 2015 11:40:55 PM CEST, Claudio Allocchio wrote:
> ... but I just tried to extend the question of "(positive) DSNs 
> non repudiation" to the open Internet, trying to see if we have, 
> if any, possible mechanisms to do so, without enforcing 
> additional rules which you can apply only within a closed 
> regulated environment.

I haven't tested it or even considered this use case when I set up the 
server, but the Postfix version I use is less than ten years old and I do 
use DKIM. So I think it's worth trying: Send me mail with an entropy-rich 
ENVID and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed 
success DSN.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 12 Jan 2015 09:59:44 +0100 (CET)

On Mon, 12 Jan 2015, Arnt Gulbrandsen wrote:

> server, but the Postfix version I use is less than ten years old and I do use 
> DKIM. So I think it's worth trying: Send me mail with an entropy-rich ENVID 
> and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed success 
> DSN.

OK, I need to check also my Postfix setup for the ENVID, and then I'll 
make the test! back later...

>
> Arnt
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2015 02:10:11 -0000

>make the test! back later...

Don't forget to check whether the d= domain in the DKIM signature has
any perceptible relationship to the recipient address.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2015 06:54:19 +0000

The ENVID is only known by servers connected to either the sender or 
the recipients. Of course a server for one recipient could lie 
convincingly about another recipient.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 13 Jan 2015 08:01:59 +0100 (CET)

> any perceptible relationship to the recipient address.

ok, it seems my MTAs lx1.dir.garr.it and lx5.dir.garr.it are correctly 
supporting ENVID, so I can go on with tests... ;-)

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2015 09:36:47 -0500

> The ENVID is only known by servers connected to either the sender or the 
> recipients. Of course a server for one recipient could lie convincingly about 
> another recipient.

Good points.  What value does a DKIM signature provide on a bounce that 
has the right ENVID?

Regards,

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2015 15:45:23 +0100

John Levine answers me:
>> The ENVID is only known by servers connected to either the 
>> sender or the recipients. Of course a server for one recipient 
>> could lie convincingly about another recipient.
>
> Good points.  What value does a DKIM signature provide on a 
> bounce that has the right ENVID?

If I send mail to three people ten servers might learn the ENVID. A strong 
ENVID offers good assurange that the DSN comes either from one of the ten 
involved servers or from my keybard. The DKIM signature narrows the source 
down to one server (or at least to one organization).

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 13 Jan 2015 15:48:22 +0100 (CET)

On Tue, 13 Jan 2015, John R Levine wrote:

>> recipients. Of course a server for one recipient could lie convincingly 
>> about another recipient.

Just made the test asked by Arnt. Here is the DSN with full headers:

-----------------------------------------------------------------------------

>From [email-masked] Tue Jan 13 15:28:03 2015
Date: Tue, 13 Jan 2015 14:24:47 +0000 (UTC)
From: [email-masked] (Mail Delivery System)
Subject: Successful Mail Delivery Report
To: [email-masked]
Auto-Submitted: auto-replied

This is the mail system at host strange.aox.org.

Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

                    The mail system

<[email-masked]>: delivery via local: alias expanded

     [ Part 2: "Delivery report" ]

Reporting-MTA: dns; strange.aox.org
Original-Envelope-Id: 13JAN2015152214010512
X-Postfix-Queue-ID: 1DD91FA0068
X-Postfix-Sender: rfc822; [email-masked]
Arrival-Date: Tue, 13 Jan 2015 14:22:29 +0000 (UTC)

Final-Recipient: rfc822; [email-masked]
Original-Recipient: rfc822;[email-masked]
Action: expanded
Status: 2.0.0
Diagnostic-Code: X-Postfix; delivery via local: alias expanded

Return-Path: <[email-masked]>
Received: from 140.105.1.2 (unknown [140.105.1.2])
 	by strange.aox.org (Postfix) with ESMTP id 1DD91FA0068
 	for <[email-masked]>; Tue, 13 Jan 2015 14:22:29 +0000 (UTC)
From: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
Date: 13-Jan-2015 15:23 CET
Subject: ENVID + NOTIFY test

-----------------------------------------------------------------------------

The Delivery Report part contains the correct ENVID used to send (and the 
DSN was also sent back with IPv6, but this does not matter).

But I do not see a DKIM signature in the DSN...

>
> Good points.  What value does a DKIM signature provide on a bounce that has 
> the right ENVID?
>
> Regards,

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2015 15:55:37 +0100

> Just made the test asked by Arnt. Here is the DSN with full headers:

Thank you.

> But I do not see a DKIM signature in the DSN...

I'm afraid this means that if you're moderately competent and set up DKIM 
in the way the top five google results suggest, the server will not sign 
DSNs.

If a sender chooses an unguessable ENVID and uses NOTIFY=SUCCESS, then this 
means that the sender will get a more or less unforgable delivery ack from 
software that's currently fairly widely deployed (with no standards work 
needed).

But without a DKIM signatura, third parties need not believe that. The 
sender might know that there was only one recipient, so only servers on the 
path to the recipient could've acked. But the sender won't be sure which 
one, and third parties need not trust this at all.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2015 15:51:23 -0000

>But without a DKIM signatura, third parties need not believe that.

Unless you have some way to know what servers handle what mail, which
you don't, a DKIM signature provides no benefit.  You send mail to
[email-masked], my server responds with a DSN signed by
miucha.iecc.com.  Now what?

Also keep in mind that anyone with access to the message can produce a
100% authentic DSN, either by forwarding it to a bad address, or just
by faking one up and mailing it out, quite likely getting it signed on
the way.  All a DSN really tells you is that someone saw the message,
and it's entirely up to you whether you believe what the DSN says
about it.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2015 18:14:14 +0100

> miucha.iecc.com.  Now what?

Now I have a DSN with ENVID+DKIM, ie. I know someone signed for having 
performed successful final delivery, and I know that someone is called 
miucha.iecc.com.

If nonreputiation turns out to matter for this particular message, you 
might perhaps want to disclaim ever having received the message and signed 
for it. If you can change miucha's DKIM keys before I've asked forty-two 
neutral third parties to verify the DKIM signature, you can repudiate the 
message. If not, you cannot.

It's not the world, but it is something. I like it since it's cheap.

> and it's entirely up to you whether you believe what the DSN says

I do have access to the test messages Claudio sent me earlier today and do 
not see the ENVID anywhere. While I could forge a DSN without the ENVID and 
get it signed, Claudio might regard the result as less than 100% authentic.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 14 Jan 2015 11:26:07 +0100 (CET)

> performed successful final delivery, and I know that someone is called 

Correct. And technically speaking, nothing more. But as a sender I have 
some non easily repudiable (see below) information.

How can I (the sender) know that the DSN sender IS the one which was 
suppoused to make the final delivery? Very complicated, nearly 
impossible... maybe some "external tool" can help... but this is not the 
point... I sent a message, and somebody declares it delivered it and 
cannot repudiate this declaration.

> If nonreputiation turns out to matter for this particular message, you might 
> perhaps want to disclaim ever having received the message and signed for it. 
> If you can change miucha's DKIM keys before I've asked forty-two neutral 
> third parties to verify the DKIM signature, you can repudiate the message. If 
> not, you cannot.
>

... there is a technical (implementation) problem, though... DSNs come 
with MAIL FROM:<> ... and as far as I know (and Arnt also verified this 
problem) current implementations do not DKIM sign a message with such a 
MAIL FROM SMTP envelope... (maybe I'm wrong... but I do not know of any 
way to make this...).

> get it signed, Claudio might regard the result as less than 100% authentic.

ENVID+NOTIFY makes impossible to forge a DSN by accessing the message 
after delivery. To make false DSNs if EVNID is used, you need to act 
inside the MTAs chain (routing system), e.g. to spoof the DNS to place an 
MTA-in-the-middle attack.

If you are just the real MTA suppoused to make the final delivery to the 
correct mailbox, and instead of doing this, you deliver it somehwere else, 
you will be responsible because you DKIM signed the DSN (like a post 
office delivering my mail to my neighbour and declaring he put it into my 
mailbox).

So... the MTA-in-the-middle (DNS spoofing) is the only tricky case in 
current Open Internet (as DNSSEC is not yet there...). In such a bad case, 
the message is intercepted and delivered somehwere else than the real 
recipient, and the attacker MTA issues a DKIM signed DSN with correct 
ENVID... but its DKIM key is not the one of the genuine MTA. If DNS is 
spoofed, then the sender can only make an "out of band" verification 
etc... but here we are now in case which is very complex and out of scope 
for most of the normal cases I was thinking on with the original question.

Not a perfect solution... as Arnt says... but (if we know how to make 
signatures of <> !) usable... and likely no need of any protocol 
development. Am I completely wrong?

all the best!

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 14 Jan 2015 11:56:13 +0100

Claudio Allocchio writes:
> ... there is a technical (implementation) problem, though... 
> DSNs come with MAIL FROM:<> ... and as far as I know (and Arnt 
> also verified this problem) current implementations do not DKIM 
> sign a message with such a MAIL FROM SMTP envelope... (maybe I'm 
> wrong... but I do not know of any way to make this...).

I looked closer, and I now think many current mail servers will sign DSNs.

The envelope of a DSN says <>, but the From field of most DSNs says 
something along the lines of [email-masked], and the most common 
DKIM implementation looks at the latter when choosing whether to sign, not 
the former. In my case it wasn't set up to sign for all the domains (long 
story), notably not the domain it used in the DSN.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 14 Jan 2015 14:15:42 +0100 (CET)

On Wed, 14 Jan 2015, Arnt Gulbrandsen wrote:

>> ... there is a technical (implementation) problem, though... DSNs come with 
>> MAIL FROM:<> ... and as far as I know (and Arnt also verified this problem) 
>> current implementations do not DKIM sign a message with such a MAIL FROM 
>> SMTP envelope... (maybe I'm wrong... but I do not know of any way to make 
>> this...).
>
> The envelope of a DSN says <>, but the From field of most DSNs says something 
> along the lines of [email-masked], and the most common DKIM 
> implementation looks at the latter when choosing whether to sign, not the 
> former. In my case it wasn't set up to sign for all the domains (long story), 
> notably not the domain it used in the DSN.

you are right... here is the DKIM signed DSN coming from my MTAs including 
the non disclosed (into the message) ENVID field:

----
>From [email-masked] Wed Jan 14 12:24:32 2015
Date: Wed, 14 Jan 2015 12:24:29 +0100
From: Mail Delivery Subsystem <[email-masked]>
To: <[email-masked]>
Subject: Return receipt
Auto-Submitted: auto-generated (return-receipt)

The original message was received at Wed, 14 Jan 2015 12:24:29 +0100
from lx1.dir.garr.it [193.206.158.2]

    ----- The following addresses had successful delivery notifications -----
<[email-masked]>  (successfully delivered to mailbox)

    ----- Transcript of session follows -----
<[email-masked]>... Successfully delivered

     [ Part 2: "Delivery Status" ]

Original-Envelope-Id: LOCALTEST14JAN2015122214010512
Reporting-MTA: dns; cyrus-c1v2.dir.garr.it
Received-From-MTA: DNS; lx1.dir.garr.it
Arrival-Date: Wed, 14 Jan 2015 12:24:29 +0100

Final-Recipient: RFC822; [email-masked]
X-Actual-Recipient: RFC822; [email-masked]
Action: delivered (to mailbox)
Status: 2.1.5
Diagnostic-Code: SMTP; 250 2.1.5 ok
Last-Attempt-Date: Wed, 14 Jan 2015 12:24:29 +0100

From: [email-masked]
To: [email-masked]
Subject: DKIM+ENVID local test
Date: 14-JAN-2015 12:24 CET
----

So, for any further test we can point in case to lx1.dir.garr.it and 
lx5.dir.garr.it...

With such a DSN, the sender can be sure that somebody called 
cyrus-c1v2.dir.garr.it has delivered the message he sent marked as
LOCALTEST14JAN2015122214010512 to a mailbox named 
[email-masked]

and

the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this 
machine generated the DSN.

Is this enough? I guess that for average use over the Open Internet "as it 
is now" this IS enough, and also in case one legal case can say it is 
enough. DNSSEC would defintly fix also the trust problem... but ...

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 14 Jan 2015 14:22:55 +0100 (CET)

ops... sorry, I copy/pasted the wrong DSN example (the one where I foced 
the ENVID to be shown in the headers - not the default!).

Here is the corect couple of "received message" and "DSN":

---
>From [email-masked] Wed Jan 14 14:07:29 2015
Date: Wed, 14 Jan 2015 14:06:55 +0100
From: [email-masked]

test
---

the DSN:

---
>From [email-masked] Wed Jan 14 14:07:31 2015
Date: Wed, 14 Jan 2015 14:07:29 +0100
From: Mail Delivery Subsystem <[email-masked]>
To: <[email-masked]>
Subject: Return receipt
Auto-Submitted: auto-generated (return-receipt)

The original message was received at Wed, 14 Jan 2015 14:07:29 +0100
from lx1.dir.garr.it [193.206.158.2]

    ----- Transcript of session follows -----

Original-Envelope-Id: LOCALTEST14JAN2015BIS122214010512
Reporting-MTA: dns; cyrus-c1v2.dir.garr.it
Received-From-MTA: DNS; lx1.dir.garr.it
Arrival-Date: Wed, 14 Jan 2015 14:07:29 +0100

Last-Attempt-Date: Wed, 14 Jan 2015 14:07:29 +0100

Date: Wed, 14 Jan 2015 14:06:55 +0100
From: [email-masked]
---

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Jan 2015 09:15:31 -0800 (PST)

> ...

> machine generated the DSN.

Actually, it can do no such thing, for the simple reason that most systems
that sign DKIM mail blindly sign anything that an authenticated user sends out
that has the appropriate domain in the From: field. So all someone who
happens to have an account on the system has to do is intercept the message,
then send out a DSN for that message using their account. That message will
be DKIM signed along with all the rest of the mail that system sends out.

And even in the unlikely event that you can trust all your users, can you trust
all their equipment not to have been messed with? No, I didn't think you could.

Of course there may be evidence of this being done: IP addresses in the
DSN header, etc. And the log files on the receiving system, assuming a
sufficient level of detail and retention, will definitely tell the real
story.

But regardless, my point is made: If you're operating in a scenario where
there's a significant risk of mail being intercepted, then DKIM signatures
offer little if any additional assurance.

And before anyone says that the fix for this is to prevent regular users from
submitting DSNs, allow me to point out that there are any number of mail
reinjection/forwarder/downloader/hosted-domain scenarios where this is an
essential thing to be able to do. Indeed, by blocking those DSNs, you may be
causing a problem that's pretty close to the one you're trying to solve.

> enough. DNSSEC would defintly fix also the trust problem... but ...

The evidence on the ground says that unsigned DSNs are enough for most email
users.

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 14 Jan 2015 22:53:09 +0100 (CET)

> that has the appropriate domain in the From: field.

True... but...

> So all someone who

but he/she cannot know the ENVID value. It is not in the message (see my 
correct couple of "message"+"DSN"), and it is "lost" on the recipient MTA 
after delivery. So the DSN the "interceptor" generates is missing one 
element (the ENVID value) and the sender can resonably suspect something 
is wrong. The "ENVID" you can intercept only on the fly transaction.

> all their equipment not to have been messed with? No, I didn't think you 

No, I cannot trust both users and equipment... but the sender can find out 
easily (no ENVID value in the DSN) that the DSN is fake, and see below 
your own observation...

> sufficient level of detail and retention, will definitely tell the real

And this is the "notary" function of the receiving system. So it will be 
evident what happened.

> offer little if any additional assurance.

True, mail can be intercepted and DSNs can be faked, but with the 
combination of an additional field, making fake DSNs is much more 
complicated, and makes the quite evident. Do you agree on this?

> causing a problem that's pretty close to the one you're trying to solve.

I agree and this has not to be done, there is no need. It is not problem 
if a user can submit a fake DSN, if there are easy ways to find out the 
trick and invalidate the fake DSN, is it?

> The evidence on the ground says that unsigned DSNs are enough for most email

True... but not if you find somebody who then negate he ever received the 
message in the mailbox  (reading it it's a completely different story).

I think that having a setup where an MTA cannot negate it sendout that 
specific DSN, and it is evident if the DSN was faked by a user or by some 
other system/process is further level of assurance. Most users will not 
care in many cases of this further level, but some will: imagine I want to 
send in via email my application for a job within a deadline, and need to 
prove I sent it and it was delivered in time to a mailbox, and I need some 
reasonble way to prove this is case somebody deny it was delivered...

As we said in the beginning, in a regulated scenario (closed community) we 
can even give legal value to mails and DSNs, but the above method can give 
some reasonable "+" value also in an Open invironment...

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Jan 2015 13:59:48 -0800 (PST)

> but he/she cannot know the ENVID value.

Of course they do. In my proposed scenario they intercepted the message and it
was part of the transaction.

But this is really beside the point. The issue at hand is your claim that, to
use your own words, "the owner of cyrus-c1v2.dir.garr.it cannot resonably
repudiate that this machine generated the DSN". I just showed that that claim
isn't reasonable in general, and that in particular DKIM adds almost no
additional value in this context.

All the owner of cyrus-c1v2.dir.garr.it has to do is point out that the message
could have been intercepted, the ENVID determined, and the DSN forged. And then
deline your request for them to check their logs, because why should they waste
their time doing that for you?

> It is not in the message (see my

You seem to have a very different understanding of how the DSN extension works
than I do.

> And this is the "notary" function of the receiving system. So it will be

Not to the recipient of the DSN, it won't. Even if they check both the ENVID
and DKIM signature.

> complicated, and makes the quite evident. Do you agree on this?

You appear to be focusing on a threat I see as a nonissue - that of sending
random DSNs to people that don't correspond to a message they actually sent. Or
alternately, on DSNs sent to people with knowledge of the message content only
and no knowledge of the full transaction or interference in the actual message
transfer.

If you want to make a cogent case for the serious dangers inherent in receiving
a fake failure DSN for a message that was actually delivered, or a success DSN
(which the originator almost certainly didn't ask for) in addition to the
failure DSN for a message that failed, or some other combination, I'll be happy
to consider it. But until you do, I regard this as having nuisance value only.

> trick and invalidate the fake DSN, is it?

There aren't any in the scenario I proposed.

> other system/process is further level of assurance.

It isn't because there is no such assurance. See above.

> Most users will not

In this scenario the service you actually want is nonrepudiation of submission
and nonrepudiation of transfer. (The reality on the ground is that so few large
email services support the DSN extension that getting confirmation, let alone
nonrepudiation, of delivery through the use of success DSNs is not really
practical. But nonrepudiation of transfer is good enough in this case.)

And the way you get this is through a third party service, which in effect
signs the combination of your message, the time it was sent, and the log
showing its successful transfer to the destination system.

This is precisely the service that RPost, and probably a bunch of others,
provide. For a fee, of course, but if you really need this sort of assurance
you should be prepared to pay for it.

Sure, it would be nice to be able to get this capability without having to pay
for it. But the reality is that nobody with any sense is going to accept the
potential liability of, say, warranting that the DKIM signatures on success
DSNs actually provide nonrepudiation of delivery.

> some reasonable "+" value also in an Open invironment...

Not really. See above.

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 15 Jan 2015 00:53:03 +0100 (CET)

:-)

let me continue a bit this brainstorming (also because it helps in 
clarifying some scenarios)...

> was part of the transaction.

a "normal" user of that system can intercept the message during the 
transation? No, unless the machine has been compromised (but in such a 
case we are in a different scenario). A system administrator can do that, 
of course, but again... we are in a different scenario where something 
has already gone quite wrong there. If we consider these scenarios, also 
third party certifications can go really wrong if machines or 
administrators are "compromised".

> could have been intercepted, the ENVID determined, and the DSN forged.

So they admit they have a compromised machine or bogus administrators.
And yes, in such a situation they can deny... but they also declare a very 
bad unreliable service level (or a bad reputation, if you like).

> And then deline your request for them to check their logs, because why 
> should they waste their time doing that for you?

True, if they are unrealiable or just acting non correctly they can do 
that.

> You seem to have a very different understanding of how the DSN extension 

? :)

> Not to the recipient of the DSN, it won't. Even if they check both the ENVID

True, but (at least IMHO) we are in a scenario where there is something 
really wrong at the recipeint side.

> random DSNs to people that don't correspond to a message they actually sent.

no, this is not my issue.

> Or

which is the normal end user case.

> a fake failure DSN for a message that was actually delivered,

no again this is not my issue.

> or a success 
> DSN
> failure DSN for a message that failed, or some other combination,

Again not this issue.

I'll be 
> happy

The scenario (and issue)  is (I hoped it was already clear):

  - the user sends a message asking explicitly (via the MUA for example)

    NOTIFY=SUCCESS,FAILURE for one (or all) recipients;

    and the sender wants to know that the message was deivered to a mailbox
    which hopefully belongs to the intended recipient; and the sender wants
    some assurance that the postive DSN he receives is genuine and cannot
    be easily repudiated by the people running the recipient mailbox
    system.

  - if the sender receives a failure DSN, even if the message was actually
    delivered and this happen for whichever reason, again it is not an
    issue here; the sender has indeed accomplished a positive transaction
    to the recipient mailbox, but he thinks he has not. So... he will try
    again to send the message. Double delivery is not an issue for him.

is this clear enough now ? (sorry if it was not... I thought it was...)

> There aren't any in the scenario I proposed.

if the recipient site is compromised, no, there aren't. But it is a 
localized problem at the recipient site. It's a different problem.

> and nonrepudiation of transfer.

yes, see a more detailed description above.

>  (The reality on the ground is that so few 
> large

Large email service providers have other serious issues, too :-) Free 
service usually means poor service, and I'm not considering them part of 
this scenario. Users needing a more serious service either are lucky to 
belong to some communities (the R&E one for example) or must be willing to 
pay for a better service, of course.

> you should be prepared to pay for it.

I know them and how they work. I'm exploring if there is a different 
mechanism to obtain the same assurances, without a third party, and using 
existing protocols... and, if not, if there can be additional protocols to 
do this in an open environment.

> DSNs actually provide nonrepudiation of delivery.

even in the case when you are the owner and administrator of the 
receiging system issuing these DKIM signed success DSNs ? and you have 
full control on your logs and maiboxes? Isn't is the same situation of the 
third party services, running the central MTA?

thanks for you time, Ned ;-)

---

From: Ned Freed <[email-masked]>
Date: Sat, 17 Jan 2015 20:26:51 -0800 (PST)

> So they admit they have a compromised machine or bogus administrators.

They admit nothing of the sort. Messages in transit across the open Internet
can be intercepted in various ways having nothing to do with the security of
the end site. Or the compromise could have occured on the sending system.
(Last mile connections are especially vulnerable, and almost always beyond
the ability of sites to effectively secure.)

Indeed, we're currently expending a hell of a lot of effort in the IETF
to try and improve the overall security of email in transit. Are you actually
arguing that this isn't a vulnerability and this work is unnnecessary?

And on the receiving system - and this is my main point - all that's needed is
a regular user account. Nothing else. I repeat: How many sites can vouch for
the integrity of every user with a regular account on their system?

> bad unreliable service level (or a bad reputation, if you like).

They need declare nothing of the sort. See above.

> True, if they are unrealiable or just acting non correctly they can do

A site telling you to suck it for such a request has nothing to do with being
any of those things. DKIM isn't entirely free of cost, so people who attach
DKIM signatures do so for a particular reason, usually part of some scheme for
insuring delivery of legitimate mail and/or attempting to detect forgery
attempts. I very much doubt there's anyone, anywhere, who attaches DKIM
signatures to DSNs with the intention of providing nonrepudiation of delivery.
as a service.

So if you ask for such information, assuming they understand what you're asking
for (very big assumption), and assuming they know how to dig such things out of
their logs (another big assumption), and assuming they have such logs (another
big assumption), then you kind of need to assume they understand the potential
liability they are undertaking if they help you, in which case I doubt they'll
cooperate. I know I damned well wouldn't in that position, no matter what kind
of site I was operating.

				Ned