Subject: Re: [EAI] RFC 5335

From: Shawn Steele <[email-masked]>
Date: Wed, 20 Apr 2016 19:11:18 +0000

Speaking personally/unofficially:

I'm unable to see the original article as it seems to be pay-to-read, however I concur with John's statement.  A quick search didn't find other material about these concerns, and given the error's John mentions I wouldn't put a lot of weight into that article.

Many mail clients/servers use additional headers & stuff for their own purposes.  Without more information about the perceived problem it's hard to comment on it.

-Shawn

----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Apr 2016 12:33:43 -0400
From: John C Klensin <[email-masked]>
To: Alan Ayres <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAI] RFC 5335
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Alan,

Thanks to Cindy for forwarding this.  A few comments inline below; others on the WG mailing list may have things to add.

--On Tuesday, April 19, 2016 08:11 -0500 Alan Ayres <[email-masked]> wrote:

>  From:   Cindy Morgan via RT <[email-masked]> 
>  To:    <[email-masked]> 
>  Sent:   4/18/2016 4:46 PM 
>  Subject:   [www.ietf.org/rt #119754] RFC 5335 
> 
> Alan,
>  
> You have reached the IETF Secretariat, and as such, we are not 
> qualified to  answer your question.
>  
> It looks like RFC 5335 was product of the Email Address 
> Internationalization  Working Group, which concluded back in 2013. 
> However, the mailing list for that  group is still active, and you may 
> have better luck if you try your question
> there. The address for that mailing list is: [email-masked]   
> You may also want to note that RFC 5335 was obsoleted by RFC
> 6532  <http://www.rfc-editor.org/info/rfc6532> in 2012. 
>  
> Best regards,
> Cindy
>  
> On Fri Apr 08 08:14:58 2016, [email-masked] wrote: 
>> Recently a part by iSHERIFF titled "Office 365 Security: Why you need  
>> to be worried" came across my desk slamming Office 365.

>> Per the article, a claim is made that Office 365 does not follow  
>> current RFC standards for email headers.

I can't comment on Office 365 at all and, since I've never installed and used Outlook, have no firsthand information about how it handles non-ASCII addressing.  However, it has been my impression from earlier discussions that the intent was to make it standards-conforming when it was upgraded to handle non-ASCII
mailbox names.   There are people on this list who are probably
much more familiar with it.  They may want to comment.

>> The claim
>> goes on to  suggest that a lack of RFC 5335 exposes anyone to 
>> unauthorized  intercept, editing and the ability to resend these 
>> messages with  malicious content within the headers of the message. 
>> As you appear  to be an authority of RFC 5335, I was hoping you would 
>> add your  input to these claims as pertaining to RFC 5335.

First of all, RFC 5335 was an Experimental specification, published to gain experience with the idea of non-ASCII email addresses and headers.  I was never a standard of any type and anyone complaining about non-conformance to it has, at best, a fundamental misunderstanding about the relationships involved.
The standard most closely related to 5335 is, as Cindy mentioned, RFC 6532.  I recommend reading RFC 6530 as well and probably first.

Second, I don't understand the attack model in the claims you describe.  The SMTPUTF8 work is rather carefully designed to ensure that messages with non-ASCII addresses (mailbox names) or headers that do not conform to the ASCII limitations of RFC 5322 are never delivered to systems that do not support them.  If those rules, described in RFC 6530 and 6531, are followed, then a system that lacks adequate support would never see such a message, much less be in a position to resend as you indicate.
I don't remember, but it may be that the model of RFC 5335 could create such a vunerability -- the major difference between the earlier experimental work and the standards track documents is that the earlier work included provisions for trying to rewrite addresses and messages to allow them to go through in an ASCII-only environment while the standards recognize that such attempts are likely to cause far more problems than they solve
-- but the standards, AFAIK, do not.

Of course, partial implementations that allow non-ASCII addresses or headers without conforming to the standards could get themselves into all sorts of trouble, but that is true of email headers and transmission generally.

If "iSHERIFF" thinks that there are attack vectors for implementations of the standards specified in RFC 6530 - 6533, it would be good if he or she would get on this list and explain them.  No one really cares about RFC 5335 any more.

  --john
    (For identification, Former Co-Chair of the IMA WG, co-author RFC 6530, editor RFC 5321)

------------------------------

Message: 2
Date: Wed, 20 Apr 2016 11:18:32 -0700 (PDT)
From: [email-masked]
To: John C Klensin <[email-masked]>
Cc: Alan Ayres <[email-masked]>, [email-masked]
Subject: Re: [EAI] RFC 5335
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

FWIW, I dug up the actual report, which is available for download here:

http://windowsitpro.com/isheriff/office-365-security

The relevant part of the report appears to be this paragraph:

             Office 365 Emails Use Some Non-Traditional Headers

  Office 365 not following current RFC internet standards for email headers
  leaves your companies emails open to several vulnerabilities. RFC 5335 covers
  internationalized email headers, this standard allows the transmission of email
  headers using non ASCII characters. ASCII characters have been exonerated and
  exploited worldwide. RFC 5335 uses a new method including UTF-8, which is an
  encoded form of Unicode text. Also the message can only be delivered if
  authorized by an SMTP extension. By ignoring this standard, Office 365 is
  allowing anyone with the knowledge access to intercept, edit, and possibly
  resend emails with malicious content in the headers of the message.

IMO this makes little if any sense. As the text points out, you can't get EAI messages without supporting the associated SMTP extension, which AFAICT is not presently supported.

Of course nothing prevents someone from attempting to send a message containing
UTF-8 addresses without the extension. But this is just a specific case of the more general problem of sending illegal garbage around - a problem that's been present in email since its inception. In fact one way to view EAI is that it makes a small subset of that garbage legal, which actually creates a more complex security problem for the system.

In any case, mail systems have to defend against invalid inputs. It has always been this way and likely always will be. Whether or not EAI is supported is largely orthogonal to this.

				Ned

P.S. No doubt it's mean of me, but I simply can't resist quoting another part of this report. It says:

           Microsoft MIME Doesn't Follow RFC; More Open To Malware

  Microsoft MIME (Multipurpose Internet Mail Extension) is an application that
  allows for the transfer of different files through the internet. For a file
  transfer to happen successfully both the file servers and the browsers must
  have the same MIME versions applied. Microsoft MIME latest version follows the
  following RFC (Request For Comments) Internet Standards: RFC 2311, RFC 2312,
  RFC 2632, and RFC 2634. Version 3 of Microsoft MIME supports all versions of
  outlook and exchange after 2000 and 5.5. The following RFCbs have been left out
  and leave Microsoft MIME very vulnerable to certain malware: RFC 959 and RFC
  5797. Both of these RFCs deal with FTP (File Transfer Protocol) and without
  them, they leave Microsoft MIME vulnerable to several serious attacks which
  could lead to malware infestation. The following attacks have been confirmed in
  applications that do not follow RFC 959 and RFC 5797:

  <list of FTP vulnerabilities omitted>

I'm not going to comment further except to note that RFC 2311-2645 are all S/MIME specifications.

------------------------------

Subject: Digest Footer

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

------------------------------

End of IMA Digest, Vol 109, Issue 2
***********************************