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

[S Moonesamy <[e-mail]>]

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