Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03

[John C Klensin <[e-mail]>]

--On Sunday, March 07, 2010 10:40 -0800 Ned Freed
<[e-mail]> wrote:

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

Yes, me too.

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

FWIW, I agree with Ned.


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

Well, BINARYMIME might be slightly more efficient in mounting an
attack on a really stupid, mostly MIME-ignorant,
firewall/gateway.  On the other hand, the security risk there
comes from the "really stupid, mostly MIME-ignorant" part, not
the SMTP transport mechanism.   So, if one wanted to say
something relevant in the Security Considerations section, it
would be something like "Users of the email system should be
aware that ignorant, non-conforming, and incompetent
implementations of this and other email specifications can
create vulnerabilities.  Such implementations should be
avoided".  But come on now...  :-(

I agree with Ned about size relationships, too.
>...

     john