> 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.

This is fine with me as well.

> > 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.

I have to strongly object to adding this, because this is quite simply at odds
with reality. One of the main principles in MIME is to be transport neutral,
that is, the semantics of what can be tranports *do* *not* change irrespective
of whether the underlying transport is 7bit, 8bit, or binary capable.

Indeed, I have to say I'm somewhat astounded that everyone seems to have lost
sight of this very basic principle, so if we're going to clarify anything in
this secutity considerations section, it should be exactly the opposite of this
claim. Something like

  Since MIME semantics are transport neutral the 8bitMIME option provides no
  added capability to dessiminate maleare than is provided by unextended 7bit
  SMTP.

would be fine to say here.

> 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.

That's true but beside the point. Unless you're going to argue that the reduced
size you can get from BINARYMIME (and to a much lesser extent 8bitMIME) is a
significant factor, there is sinmply no relevant difference in their
capabilities.

And as for the whole size thing, if we're truly worried about the existance of
some sort of virus that both can be represented in 8bit without encoding and
gains substantial benefit from the size difference due to the lack of encoding,
well, I'm afraid I'm going to have to ask for some sort of proof that such a
thing actually exists because I certainly haven't ever heard of it.

It's one thing to spend time describing an attack that's purely hypothetical
but entirely possible. It's quite another to waste time on attacks that are
entirely fanciful.

> > Anyone object, suggest different text, or additional text?

Yes, see above.

				Ned