I definitely understand the concerns of passing around the malware via
email. If we feel that they *must* be sent, we *could* encrypt the
attachment (pick your poison, such as AES), and include the password in
another header.
Just thinking out loud,
Tony Hansen
On 7/24/2011 6:53 PM, Murray S. Kucherawy wrote:
<co-chair>
Barry and I received the following feedback about the ARF base document from
someone who does not wish to join the mailing list and does not wish to
participate in the working group directly. We've agreed to forward these
comments to the working group for its consideration, but also agree that one
person's concerns (especially when that person doesn't want to do the work of
advancing them through the working group) are not sufficient to spin up an
update effort.
So, if the working group wants to do something with some or all of this
material, great, we can talk about starting that effort. If not, then that's
fine too.
Some of this stuff also applies to a couple of our open documents, so the
various authors (JD mostly, I think) could consider them there.
</co-chair>
<participant>
As far as the base stuff goes, some of this stuff looks reasonable, but none of it looks
critical to me. Thus, if there's no critical mass to create an RFC5965bis effort, they
could just be logged as errata or something like that so they fall in the "deal with
this someday" bucket.
</participant>
<feedback>
I am just working through the most recent version to update our filters to
use the latest proposal, and am in the process of also converting our virus
reporting to the ARF. In that process I found a number of concerns with ARF
and aborted that conversion:
1) I consider it extremely rude and dangerous to transmit malware across the
Internet even in the form of an ARF, apart from the fact that virus filters
at the ISP level and/or the recipient's level may well catch the malware,
create a report of that malware (thus creating a loop), and at the same time
firewall the offending IP (our mail server). Hence the proposal to return the
complete message in case of reporting a virus is a very bad idea. Instead,
only the header of the offending message should be returned.
The proposal should therefore prohibit the return of the full message in case
of feedback type virus and instead require the return of the mail header
only.
This also requires to change the content type of the last ARF section from
message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable).
2) Because with just returning the header the recipient is no longer able to
determine which malware was being sent, an according reporting field is
needed in the ARF. I'd propose to use:
Reported-Description:
or
Reported-Malware:
the first of which can be used not only for virus reporting, but should be
required for feedback type virus and should contain the full name of the
virus as reported by the virus scanner.
3) Because the virus names vary from each virus scanner tool, we also need to
identify the virus scanner reporting the malware. The name of the virus
scanner should therefore be included as:
Reporting-Utility:
Required for feedback type virus, optional for other feedback types.
4) The Source IP address should be mandatory for feedback type virus.
5) I'd phase out the feedback type virus in favour of feedback type malware
(which is the same, just broadening the use to include worms, downloaders,
.. which are not virus type), alternatively introduce malware as equivalent
to virus (keeping both feedback types permanently alive). I feed virus would
be too limiting for that type of reporting (virus by definition is self re-
producing, while worms, downloaders etc. are not self re-producing and
therefore by definition are not virusses).
That concludes my virus/malware-related comment to your excellent tool.
A suggestion may be whether the keyword virus should not be phased out in
favour of the word malware to open the abuse report for more generic purpose
(although virus generally is now being understood like malware anyway).
Another comment regarding the _report.domain DNS TXT entry ...
In principle that seems to be a reasonable idea, however, there's a duplicate
created that way. Right now abuse addresses are mandatory for the IP address
entries in ARIN, RIPE, ... The problem there, the databases are not really
consistent, but consistent enough that parsing of the entries for abuse
addresses is possible indeed.
I'd rather leave the (legally binding, because that is part of the contract
between ARIN/RIPE/... for IP address assignment) abuse reporting facility
with the IP assigning entities and create a standard there in either their
databases (whois) or via a global abuse address server under control of one
entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning
authorities delegated by ARIN) with the entry of the source IP address and
return of the abuse mail address (could be name server, http, whois, ...)
There is actually a huge problem with the _report.domain ... The name server
may not be under control of the ISP, subdomains may well be added by the
client. Hence a malicious client could redirect the abuse reporting to his
own mail address that way and as such completely disable abuse reporting.
Hence I consider the proposal for _report.domain TXT field to publish the
abuse mail address as serious risk and detrimental to the purpose of ARF.
I'd therefore recommend to drop that proposal in favour of what I lined out
above, most likely and easiest by creating consistency across the whois
databases (introduce a specific abuse report field there, which is currently
missing and abuse e-mail addresses are only published in the comment
fields!).
To give you an idea: our spam- and virus reporting utilities fetch the abuse
address of the ISP via whois indeed and do all the necessary parsing of the
whois entries via the source IP address.
</feedback>
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
