Subject: [EAI] RFC 5335

From: Alan Ayres <[email-masked]>
Date: Tue, 19 Apr 2016 08:11:30 -0500

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Apr 2016 12:33:43 -0400

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:

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

---

From: [email-masked]
Date: Wed, 20 Apr 2016 11:18:32 -0700 (PDT)

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.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Apr 2016 12:21:46 -0700

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

Thanks for digging up the report an extracting the relevant bits, Ned.

>    ASCII characters have been exonerated and
>    exploited worldwide.

Any idea what this sentence means?  It seems contradictory to say 
that something has been both exonerated and exploited.  (There have 
been ASCII-based attacks in the past, such as certain control codes, 
the old source-routing ("%" and "!") characters, and embedded nulls, 
but none of those have to do with EAI, and as far as I know, all have 
been fixed in current versions of any even moderately used mail 
servers.)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I pride myself on the fact that my work has no
socially  redeeming value.       --John Waters

---

From: Franck Martin <[email-masked]>
Date: Wed, 20 Apr 2016 13:35:09 -0700

Speaking personally. When I tested EAI.

MUAs tends to not care about the format of the local part. It seems
developers just take the string as is based on char boundaries found in the
RFC5322.From and other places. In most places in the code, it does not
matter what the local part is.

So, I think you would have little problems to send an email to an EAI
address

I have also noticed that postfix, if 8bits is enabled, does not care about
the local part and takes the string as is (as well as the rest of the
email). it does not even need to advertise SMTPUTF8.

Things may break because the difficulty is in handling the mailbox.

Also, very few people use EAI mailboxes. So an EAI sender is usually a
strong positive signal for SPAM.

I think I still have an EAI email address, so if you want me to send you an
email, please let me know in private.

On Wed, Apr 20, 2016 at 12:21 PM, Randall Gellens <[email-masked]
> wrote:

> Any idea what this sentence means?  It seems contradictory to say that
> something has been both exonerated and exploited.  (There have been
> ASCII-based attacks in the past, such as certain control codes, the old
> source-routing ("%" and "!") characters, and embedded nulls, but none of
> those have to do with EAI, and as far as I know, all have been fixed in
> current versions of any even moderately used mail servers.)
>
> --
> Randall Gellens
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>