Re: [EAI] RFC 5335

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

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
<[e-mail]> wrote:

>  From:   Cindy Morgan via RT <[e-mail]> 
>  To:    <[e-mail]> 
>  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: [e-mail]   
> 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, [e-mail] 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)