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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Mar 2010 12:08:58 +0000

Subject: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
From: Stephen Kent <[email-masked]>
To: [email-masked]
Date: Fri, 26 Feb 2010 15:05:14 -0500
List-Id: Security Area Directorate <secdir.ietf.org>

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This is a very, very brief document that is targeted to obsolete RFC 
1652. It addresses transport of 8-bit (vs. ASCII) data via SMTP, 
consistent with carriage of MIME 8BIT content encoding. This document 
is part of the YAM effort, updating the series of Internet email 
standards.

The security considerations section consists of only one sentence: 
"This RFC does not discuss security issues and is not believed to 
raise any security issues not already endemic in electronic mail and 
present in fully conforming implementations of [RFC5321]." RFC 5321 
(the updated SMTP spec) has an extensive security considerations 
section, so this is a reasonable reference. 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 :.

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

Subject: Re: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
From: Alexey Melnikov <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Date: Sat, 27 Feb 2010 19:48:24 +0000

Hi Stephen,

Stephen Kent wrote:
 [...]

> The security considerations section consists of only one sentence: 
> "This RFC does not discuss security issues and is not believed to 
> raise any security issues not already endemic in electronic mail and 
> present in fully conforming implementations of [RFC5321]." RFC 5321 
> (the updated SMTP spec) has an extensive security considerations 
> section, so this is a reasonable reference. 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.

Can you elaborate of your concern hear?
If you can suggest some text, that would be perfect.

> One might even cite the use of this transport capability as 
> facilitating malware transmission in e-mail attachments.

Does it?

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Mar 2010 11:14:13 -0800

Hi Stephen,

Thank you for your review.

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

[snip]

>consistent with carriage of MIME 8BIT content encoding. This 
>document is part of the YAM effort, updating the series of Internet 
>email standards.

This part of the effort is to move 8BITMIME to Full Standard.  This 
document does not change the 8BITMIME specification as defined in RFC 
1652.  There was a pre-evaluation and a Sec-dir review prior to this 
document ( 
http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html 
).  It would have been helpful if the YAM WG got a review of RFC 1652 
at that time but that did not happen probably due to miscommunication 
about the process.  Please note that there hasn't been any reports of 
security issues with this 16 year old specification.

>security concerns related to transfer of 8-bit data. For example, 
>the handshake used to determine whether an SMTP sever support 
>transport capability as facilitating malware transmission in e-mail attachments

I don't understand your concern in regards to the 8-bit data 
transfer.  If you mean that support for this SMTP extension could be 
used to identify SMTP servers which do not support it, that is 
correct.  There is some text about 8-bit message content transmission 
in Section 2.4 of RFC 5321.

This transport capability does not facilitate malware transmission as 
email attachments can still be sent even if the SMTP client or server 
does not support the 8BITMIME extension.  It is only a matter of 
using MIME for the 5322 message.

Could you please clarify the security issues you have in mind so that 
I can bring them to the attention of the authors of this document?

Regards,
S. Moonesamy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Mar 2010 20:55:44 -0500

At 11:14 AM -0800 3/3/10, S Moonesamy wrote:
>...
>document does not change the 8BITMIME specification as defined in 
>RFC 1652.  There was a pre-evaluation and a Sec-dir review prior to 
>this document ( 
>http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html ). 
>It would have been helpful if the YAM WG got a review of RFC 1652 at 
>that time but that did not happen probably due to miscommunication 
>about the process.  Please note that there hasn't been any reports 
>of security issues with this 16 year old specification.

OK

>>raise any security issues not already endemic in electronic mail 
>>and present in fully conforming implementations of [RFC5321]." RFC 
>>5321 (the updated SMTP spec) has an extensive security 
>>considerations section, so this is a reasonable reference. 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
>
>correct.  There is some text about 8-bit message content 
>transmission in Section 2.4 of RFC 5321.

First, this is a minor issue, so we ought not devote to much time to 
it. I mentioned it because the tone of the security considerations 
sentence is somewhat dismissive, suggesting that the authors did not 
want to bother with this section :-). Nonetheless, it would be 
preferable  to explicitly note this side-effect of security 
considerations section, since it is not called out in the 5321 
security considerations and the text in 2.4 does not have a secruity 
focus.

>This transport capability does not facilitate malware transmission 
>as email attachments can still be sent even if the SMTP client or 
>server does not support the 8BITMIME extension.  It is only a matter 
>of using MIME for the 5322 message.

Presumably you mean to say that binary attachments that are ideal for 
delivering malware are supported irrespective of the use of this 
feature, right?  If so, that then that might also be a suitable 
comment to make in the SC section.

Steve

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Mar 2010 22:18:41 -0800

Hi Dave,

Alexey forwarded the Secdir review to the list ( 
http://www.ietf.org/mail-archive/web/yam/current/msg00366.html 
).  The Secdir reviewer clarified his comments ( 
http://www.ietf.org/mail-archive/web/yam/current/msg00368.html ).

Please address the comments.

Regards,
S. Moonesamy

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 04 Mar 2010 16:05:19 +0800

On 3/4/2010 2:18 PM, S Moonesamy wrote:
> http://www.ietf.org/mail-archive/web/yam/current/msg00366.html ). The
> Secdir reviewer clarified his comments (

Since Steve Kent is sitting a few feet away from me, here in Kuala Lumpur, I 
should probably chat with him about this...

The problem is that I'm not sure what to discuss.  His followup note does 
indicate that he has a reasonable and narrow set of concerns.  The real problem 
is that I am not sure what boundaries we -- yam -- have for these kinds of changes.

One argument is that he is suggesting non-normative clarifications.  From that 
standpoint, that seems reasonable to include for yam-related work.

A different argument is that there is, nonetheless, some actual substance to the 
changes and that that is /not/ within scope for yam.

How does the wg feel about this?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Mar 2010 11:18:00 +0000

Hi Stephen,

 [...]

>>> attachments
>> used to identify SMTP servers which do not support it, that is correct.
>
Right. ESMTP capability negotiation is a basic feature of ESMTP as 
described in RFC 5321, this is not specific to 8BITMIME.

>> There is some text about 8-bit message content transmission in 
>> Section 2.4 of RFC 5321.
>

RFC 5321 is also being revised by the YAM WG, so I would prefer any such 
text to go there.

> feature, right?

Firstly, 8BITMIME is not suitable for transferring unencoded binary 
data, it is only suitable for transfering 8bit text (e.g. textual 
documents encoded in UTF-8). BINARYMIME (a separate SMTP extension) is 
used to transfer unencoded binary data.

Secondly, the only thing that 8BITMIME changes is how certain email 
messages or message attachments are transferred. So if there is a 
malware that can take advantage of 8BITMIME, messages containing such 
malware would take less bandwidth to transfer.

> If so, that then that might also be a suitable comment to make in the 
> SC section.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Mar 2010 16:43:44 -0500

> One argument is that he is suggesting non-normative clarifications.  From
> that standpoint, that seems reasonable to include for yam-related work.
>
> A different argument is that there is, nonetheless, some actual substance to
> the changes and that that is /not/ within scope for yam.
>

This WG participant feels great about having you discuss it with him,
use your judgment, and make a recommendation to the WG about what we
should do.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Mar 2010 16:48:44 -0500

I concur with Barry.   I fear that the path Steve apparently
wants to go down --as I understand it, to incorporate warnings
in security considerations simply because a mechanism can be
used to transfer bad stuff -- leads to madness.   But I'm happy
to have you discuss it with him to see if you, together, can
find an acceptable basis for moving forward.

     john

--On Thursday, March 04, 2010 16:43 -0500 Barry Leiba
<[email-masked]> wrote:

>> One argument is that he is suggesting non-normative
>> clarifications.  From that standpoint, that seems reasonable
>> to include for yam-related work.
>> 
>> A different argument is that there is, nonetheless, some
>> actual substance to the changes and that that is /not/ within
>> scope for yam.
>> 
> This WG participant feels great about having you discuss it
> with him, use your judgment, and make a recommendation to the
> WG about what we should do.
> 
> Barry
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Mar 2010 12:38:04 +0100

>> This is a very, very brief document that is targeted to obsolete RFC 1652.
>
> Please note that there hasn't been any reports of security issues with this 16 year old specification.

RFC 4871 is of 2007 and reports an issue with it. Section 5.3 
practically says that 8bit SHOULD NOT be used. I'm not sure whether 
this is a security consideration that would incarnate Stephen's 
concern (also because, since the "relaxed" Header Canonicalization 
Algorithm does not take into account quotes, /any/ rfc2045 extension 
token breaks those signatures, not just 8BITMIME.)

---

From: Ned Freed <[email-masked]>
Date: Fri, 05 Mar 2010 06:00:53 -0800 (PST)

> token breaks those signatures, not just 8BITMIME.)

It's hardly the 8bitMIME extension's fault that DKIM is misdesigned - It isn't
at all difficult to define a signature mechanism capable of surviving encoding
changes. The DKIM group simply chose not to do it, making a design tradeoff
that severely limits DKIM's applicability.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Mar 2010 09:15:31 -0500

>> practically says that 8bit SHOULD NOT be used.
>
> It's hardly the 8bitMIME extension's fault that DKIM is misdesigned - It
> isn't at all difficult to define a signature mechanism capable of surviving
> encoding changes. The DKIM group simply chose not to do it, making a
> design tradeoff that severely limits DKIM's applicability.

Don't confuse what's sent on the wire with what's done in the
canonicalization.  DKIM doesn't prevent sending 8bitMIME... it just
says that it had better be canonicalized with RFC 2047 encoding when
you make (and verify) the signature.

Barry

---

From: Ned Freed <[email-masked]>
Date: Fri, 05 Mar 2010 06:24:31 -0800 (PST)

> canonicalization.  DKIM doesn't prevent sending 8bitMIME...

Nobody said it did. But DKIM signatures break when downgrading or upgrading of
encodings is performed, so the recommendation in the DKIM specification is that
only 7bit should be used, making 8bitMIME unnecessary.

I happen to think this is going to prove to be a poor design choice in the long
run, but that's not relevant to the present discussion. The question at hand is
whether or not this deserves any sort of mention in the 8bitMIME specification.
I believe it does not. Again, tHe bottom line is that DKIM WG opted for
canonical form simplicity over a canonical form that's robust in the face of
encoding changes. It was their engineering choice to make and they made it. But
having made it, it is also their choice to document, justify, and defend.

We simply cannot go around trying to update every specification we have to make
each one forward-aware of all subsequent specifications that touch on that
application space. It's madness to even try.

> it just

Er, no, that's not what it says at all. From Section 5.2:

   Some messages, particularly those using 8-bit characters, are subject
   to modification during transit, notably conversion to 7-bit form.
   Such conversions will break DKIM signatures.  In order to minimize
   the chances of such breakage, signers SHOULD convert the message to a
   suitable MIME content transfer encoding such as quoted-printable or
   base64 as described in MIME Part One [RFC2045] before signing.  Such
   conversion is outside the scope of DKIM; the actual message SHOULD be
   converted to 7-bit MIME by an MUA or MSA prior to presentation to the
   DKIM algorithm.

This has nothing to do with RFC 2047 encoded words and everyything to do with
the recommended non-use of 8bitMIME.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Fri, 05 Mar 2010 06:41:32 -0800

Hi Alessandro,
>token breaks those signatures, not just 8BITMIME.)

Section 5.3 of RFC 4871 sounds more like a deployment consideration 
instead of a security consideration.

The question from Stephen Kent [1] in response to my comment mentions 
that "binary attachments that are ideal for delivering malware are 
supported irrespective of the use of" the 8BITMIME extension.  Dave 
Crocker requested input from the WG on the secdir review [2].  His 
message gives a broader view of the matter (i.e. whether the change 
is within scope for the YAM WG).  If you have any comments, I would 
like to hear them.  I am not saying this because it is required by 
the IETF Standards process; I mean it.  It is less work for me if 
such discussions do not diverge from the issue at hand.  My position 
is that an issue was brought up during the Secdir review and I need 
an answer for the Responsible Area Director and YAM WG Chairs.

I wrote some notes about hostile content ( temporary link 
http://www.elandsys.com/resources/mail/draft-moonesamy-mail-security-00.txt 
).  It is not meant to be used as input for YAM WG work.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/yam/current/msg00368.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00370.html

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 06 Mar 2010 12:35:58 +0100

Hi SM,

>> RFC 4871 is of 2007 and reports an issue with it. Section 5.3 practically says that 8bit SHOULD NOT be used.
>
> Section 5.3 of RFC 4871 sounds more like a deployment consideration instead of a security consideration.

Yes, it is the deployment of a security add-on, though.

> The question from Stephen Kent [1] in response to my comment mentions that "binary attachments that are ideal for delivering malware are supported irrespective of the use of" the 8BITMIME extension. Dave Crocker requested input from the WG on the secdir review [2]. His message gives a broader view of the matter (i.e. whether the change is within scope for the YAM WG).

I don't know what "actual substance" outside of yam's scope Dave has 
been talking about.

Mail is often overlooked during generic talks about Internet security, 
where they primarily consider the web and the DNS. My feeling is that 
the WG should attempt to correct such general stance, but not at the 
cost of "leading to madness", in John's words.

> My position is that an issue was brought up during the Secdir review and I need an answer for the Responsible Area Director and YAM WG Chairs.

For the specific 8BITMIME case, I also agree with what Ned has said. 
It would sound grandiloquent to say that 8bit is dangerous because it 
is one of the many ways to break DKIM. I don't think it is a real concern.

> I wrote some notes about hostile content ( temporary link http://www.elandsys.com/resources/mail/draft-moonesamy-mail-security-00.txt ). It is not meant to be used as input for YAM WG work.

Interesting effort.

Hostile content is not the only risk. Disclosing sensible information 
is another pitfall. For example, consider attaching the "wrong" file 
and/or sending to the "wrong" recipient. Similar leakage can also 
occur with abuse reporting buttons --that will hopefully break loose 
from web based MUAs-- as users may inadvertently "throw" messages 
containing sensible data, into potentially unfriendly FBLs.

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Mar 2010 09:46:45 -0500

--On Saturday, March 06, 2010 12:35 +0100 Alessandro Vesely
<[email-masked]> wrote:

>...
> I don't know what "actual substance" outside of yam's scope
> Dave has been talking about.

YAM is deliberately chartered to advance documents, not to make
any substantive changes in specifications or do other major
work.  A reevaluation or reconsideration of general security
issues with email would certainly involve major work that is not
on YAM's current critical path.  If such a reevaluation were
required as a condition for documents advancing, then, IMO, we
need to abandon our current tasks, close the WG, and determine
whether there is energy for such an evaluation.

> Mail is often overlooked during generic talks about Internet
> security, where they primarily consider the web and the DNS.
> My feeling is that the WG should attempt to correct such
> general stance, but not at the cost of "leading to madness",
> in John's words.

Well, I would have said "becomes a separate thread", rather than
"overlooked".  Certainly a lot of energy and consideration are
given anti-spam issues, detection and stopping of email-spread
malware, phishing, etc.

To be clear, I think it would be a great idea if someone wanted
to mount an effort to do a comprehensive review of security
issues with email and the relationship (including strengths and
weaknesses) of various approaches to dealing with those issues.
On the list of things that document would turn up, "the ability
to send body parts containing other than control-character-free
plain text implies that ability to transmit malware and one had
better be careful about the handling of such body parts" is
nearly trivially obvious, even though it belongs on the list.
Presumably such a document would also discuss the issues of
header-signing mechanisms that are not robust under common
transformations (and why they are, or are not, useful anyway),
the strengths and weaknesses of authentication and privacy
protection between SMTP servers (hop to hop) in a relay
environment, the risks introduced by incompetent SMTP servers
introduced as part of firewalls, the possible risks associated
with MUAs that automatically open any body part they can and
that rely on portions of file names (rather than content-type
information) to do so, and so on.  

It is, for better or worse, a target-rich environment.

I doubt that there is energy in the IETF to develop such a
document and get sufficient consensus behind it to, e.g.,
process it as a BCP.  I'd be happy to be wrong about that.  Even
if I am not, there is always the possibility of someone
preparing such a document as an opinion piece and handing it off
to the RFC Editor as an independent submission.

But the absence of such a document and analysis should not, IMO,
block work in YAM or block the WG entirely.

>> My position is that an issue was brought up during the Secdir
>> review and I need an answer for the Responsible Area Director
>> and YAM WG Chairs.
> 
> For the specific 8BITMIME case, I also agree with what Ned has
> said. It would sound grandiloquent to say that 8bit is
> dangerous because it is one of the many ways to break DKIM. I
> don't think it is a real concern.

While I agree with the conclusion here (and have said so), I am
less interested in whether it is a real concern than I am about
whether the problem is YAM's to solve.

The response to any review comment (even one of the area-based
ones) can be "thank you for your input, but it is not in this
WG's scope; if the community believes the work is important, we
would encourage charting another group to address it".

>...
> Hostile content is not the only risk. Disclosing sensible
> information is another pitfall. For example, consider
> attaching the "wrong" file and/or sending to the "wrong"
> recipient. Similar leakage can also occur with abuse reporting
> buttons --that will hopefully break loose from web based
> MUAs-- as users may inadvertently "throw" messages containing
> sensible data, into potentially unfriendly FBLs.

Indeed.  As I suggested above, it is a target-rich environment.

     john

---

From: S Moonesamy <[email-masked]>
Date: Sat, 06 Mar 2010 07:05:37 -0800

Hello,

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.

>Yes, it is the deployment of a security add-on, though.

After reading the WG feedback, I prefer not to explore this question further.

>I don't know what "actual substance" outside of yam's scope Dave has 

I'll refer you to Dave for the authoritative answer.  My 
interpretation is that there can be a good argument in support of a 
change but that change may not be within the parameters set in the 
YAM WG Charter.  It has to be demonstrated that a change "contributes 
in a substantial and substantive way to the quality and 
comprehensibility of the  specification".

>security, where they primarily consider the web and the DNS. My 
>feeling is that the WG should attempt to correct such general 
>stance, but not at the cost of "leading to madness", in John's words.

Your last sentence sums up why it may not be a good idea for the YAM 
WG to attempt to correct that.

>It would sound grandiloquent to say that 8bit is dangerous because 
>it is one of the many ways to break DKIM. I don't think it is a real concern.

Noted.

I'll comment off-list on the last paragraph of your message as I will 
be off-topic.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 07 Mar 2010 07:01:16 +0800

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

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.

Anyone object, suggest different text, or additional text?

d/
-- 

   Dave Crocker

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Mar 2010 12:27:40 +0000

Dave CROCKER wrote:

>> receipt/relay of
> 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...
>
> 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

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

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.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 07 Mar 2010 09:55:34 -0800

At 15:01 06-03-10, Dave CROCKER wrote:
>should it contain material that is needed for other 
>specification.  It other words, it should cover security issues that are new.

I agree.

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

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

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Mar 2010 10:40:33 -0800 (PST)

> Works for me.

This is fine with me as well.

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

> 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

---

From: Tony Finch <[email-masked]>
Date: Sun, 7 Mar 2010 20:19:26 +0000

On Sun, 7 Mar 2010, Ned Freed wrote:
>  added capability to disseminate malware than is provided by unextended 7bit
>  SMTP.

+1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 Mar 2010 19:07:53 -0500

--On Sunday, March 07, 2010 10:40 -0800 Ned Freed
<[email-masked]> 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

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:
>> > 
>> 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.
> 
> this secutity considerations section, it should be exactly the
> opposite of this claim. Something like
> 
>   added capability to dessiminate maleare than is provided by
> unextended 7bit SMTP.
> 

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

---

From: S Moonesamy <[email-masked]>
Date: Mon, 08 Mar 2010 00:33:42 -0800

Hello,

This is an attempt to summarize the discussion about the Secdir 
review [1] and formulate a response.

At 03:18 04-03-10, Alexey Melnikov wrote:
>RFC 5321 is also being revised by the YAM WG, so I would prefer any 
>such text to go there.

I presume that the Area Director would be agreeable to not making any 
changes to draft-ietf-yam-rfc1652bis-03.

Dave asked for the WG's opinion [2] and made a recommendation 
[3].  There hasn't been any objection to the following text for 
Section 5 of draft-ietf-yam-rfc1652bis-03:

   This RFC does not discuss security issues and is not 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.

Alexey is not convinced that text discussing exploitation by malware 
is needed [4].  Alessandro agrees that corrections should not be made 
[5] at the cost of "leading to madness".

Ned suggested alternative text [6] and Tony Finch supported it.

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

John Klensin wrote the following text [7]:

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

I'll highlight a comment from Ned as I believe that it is pertinent 
to the YAM WG's work:

   "This is a path to madness, or more accurately, to a world where security
    considerations contain so many obvious, irrelevant, or both issues that the
    real issues specific to a given protcol or format simply get lost 
in all the
    other noise. And this is not a path which, if followed, will 
improve overall
    Internet security. To the extent it has an effect, if will be the 
opposite."

As there is no strong resolve, I suggest sending the following 
response to Sec-dir:

   The YAM WG discussed about the issues raised during the Sec-dir review of
   draft-ietf-yam-rfc1652bis-03 and concluded that:

   (i) The presence of an option negotiation mechanism is not believed to
       facilitate attacks or raise any security issues not already endemic
       in electronic mail and present in fully conforming implementations
       of RFC5321.

  (ii) Since MIME semantics are transport neutral the 8bitMIME option
       provides no added capability to disseminate malware than is provided
       by unextended 7bit SMTP.

Regards,
S. Moonesamy
YAM WG Secretary

1. http://www.ietf.org/mail-archive/web/yam/current/msg00366.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00370.html
3. http://www.ietf.org/mail-archive/web/yam/current/msg00385.html
4. http://www.ietf.org/mail-archive/web/yam/current/msg00386.html
5. http://www.ietf.org/mail-archive/web/yam/current/msg00382.html
6. http://www.ietf.org/mail-archive/web/yam/current/msg00388.html
7. http://www.ietf.org/mail-archive/web/yam/current/msg00390.html

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Mar 2010 10:10:24 +0100

On 07/Mar/10 19:40, Ned Freed wrote:
>> Dave CROCKER wrote:
>> >
>> > since it does transfer a nearly-binary object, there is some
>> > possibility that is could facilitate exploitations of this type.
>
> I have to strongly object to adding this, because this is quite simply at odds with reality.

+1, detaching from real weakens the "Security Considerations" channel.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 8 Mar 2010 11:15:16 +0100

On 03/08/2010 01:07 AM, John C Klensin wrote:
>> Something like
>>    added capability to dessiminate maleare than is provided by unextended 7bit SMTP.
>>

AOL.

(I always wondered what the point of BINARYMIME is/was.)

Arnt

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Mar 2010 08:43:24 -0800

On 3/8/2010 12:33 AM, S Moonesamy wrote:
> As there is no strong resolve, I suggest sending the following response
> to Sec-dir:
>

This is a clear and supportable stance.  And as Ned notes, a short Security 
section that is valid should be defended.

I'm entirely comfortable with my name on this document, with that position.

That said...

I'll note that confusion about the exposure this option does /not/ create seems 
to be pretty easy to suffer.  Defending against /that/ problem is probably worth 
a small amount of extra text.

The change I suggested:

 >    present in fully conforming implementations of [RFC5321] {{ ,including

Got some support.

And I have developed and even greater concern for the thinking that this type of 
binary mechanism causes a malware window.  I think we now have affirmative proof 
that the confusion is common.

d/
-- 

   Dave Crocker

---

From: S Moonesamy <[email-masked]>
Date: Mon, 08 Mar 2010 11:09:03 -0800

At 08:43 08-03-10, Dave CROCKER wrote:
>This is a clear and supportable stance.  And as Ned notes, a short 
>Security section that is valid should be defended.
>

Personally, I also consider it is a clear and supportable stance.

>I'll note that confusion about the exposure this option does /not/ 
>create seems to be pretty easy to suffer.  Defending against /that/ 
>problem is probably worth a small amount of extra text.

[snip]

>Got some support.

I agree.  BTW, I used the text you provided.

>And I have developed and even greater concern for the thinking that 
>this type of binary mechanism causes a malware window.  I think we 
>now have affirmative proof that the confusion is common.

That's fine as long as we do not have to address any confusion that 
does not contribute to the clarity of specification in a substantive way.

>So, I'll suggest that we use Ned's text:

I also used that text.

I'll post the WG response shortly.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: S Moonesamy <[email-masked]>
Date: Mon, 08 Mar 2010 11:49:02 -0800

Hi Steve,

The YAM WG discussed about the issues raised during the Sec-dir 
review of draft-ietf-yam-rfc1652bis-03 [1] and concluded that:

       of RFC 5321.

  (ii) Since MIME semantics are transport neutral the 8bitMIME option
       provides no added capability to disseminate malware than is
       provided by unextended 7bit SMTP.

Regards,
S. Moonesamy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Mar 2010 10:44:38 -0500

>       provided by unextended 7bit SMTP.

Thanks for the reply.

Steve