At 15:01 06-03-10, Dave CROCKER wrote:
The relevant part of Steve Kent's review:
I could imagine security issues that might be associated with this document
vs. 5321, since the security section of the latter document does not address
any security concerns related to transfer of 8-bit data. For example, the
handshake used to determine whether an SMTP sever support receipt/relay of
8-bit data might be used to target servers based on the lack of such support.
One might even cite the use of this transport capability as facilitating
malware transmission in e-mail attachments :.
A Security section should cover security issues that are specific to that
specification; it should not contain general-purpose tutorial material nor
should it contain material that is needed for other
specification. It other words, it should cover security issues that are new.
I agree.
I suppose there is a reasonable case to be made for some coverage of
materials that /should/ have been covered in another document, but
weren't, and are relevant to the current specification. But even
that concession makes the question of what to include a slippery slope, IMO.
Agreed.
The boundary between object and channel security, or in this case the
protocol, is not clear. Looking at review from a non-WG perspective,
there is a reasonable case. The deployment of the protocol has not
raised any security concerns. I would not pushed for such a change
within the WG during the first step as it does not fit within the
parameters set by the YAM WG charter in my individual opinion.
In any event...
The 8bitmime option does not create the potential for using SMTP option
negotations as an attack vector, such as permitting discovery of
which servers support an option. I therefore think it better /not/
to cite that in 1652bis. Given that this style of attack is not
mentioned elsewhere, I suppose a small enhancement to the current
text would be reasonable, such as:
is not believed to
raise any security issues not already endemic in electronic mail and
present in fully conforming implementations of [RFC5321] {{ , including
attacks facilitated by the presence of an option negotiation mechanism.}}
Even though 8bitmime is not a pure 'binary' mechanism, it does move
things into a binary realm. I therefore think that it /is/
reasonable to cite the potential for facilitating attacks based on
use of binary data. Hence, I propose also adding the text:
Exploitation by malware is facilitated by supporting binary data in the
transfer. The 8BITMIME option does not provide a pure binary
transport, but
since it does transfer a nearly-binary object, there is some possibility
that is could facilitate exploitations of this type.
If we add text, we also have to take into account the first line of
Section 5 which says: "This RFC does not discuss security issues".
Misguided operators might disable the 8BITMIME extension to reduce
the possibility of facilitating exploitation by malware.
I don't have any objection to adding the text. Alternatively, I do
not object to a response instead of change which says that this is
the wrong layer to address the issue as the requirements for the
transfer of mail objects as binary data are specified at a higher layer.
Regards,
S. Moonesamy
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
