Dave CROCKER wrote:
On 3/6/2010 11:05 PM, S Moonesamy wrote:
The Last Call for draft-ietf-yam-rfc1652bis-03 ended yesterday. There
wasn't
any comments. This I-D will be evaluated by the IESG on March 11. I am
waiting for a recommendation from Dave regarding the Secdir review.
Folks,
Feeling no strong resolve, myself, here's my current though:
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 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.
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.}}
Works for me.
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.
I am not convinced this is needed, as I would like to better understand
what the issue is. However I also like detailed Security Considerations
sections so I wouldn't object to adding this text either.
BTW, Arnt and myself explained to Stephen Kent the difference between
8BITMIME and BINARYMIME. So I think he now understands that 8BITMIME is
not appropriate for sending arbitrary binary data.
Anyone object, suggest different text, or additional text?
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
