Re: [EAI] RFC 5335

ned+ima@mrochek.com Wed, 20 April 2016 18:39 UTC

Return-Path: <ned+ima@mrochek.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F47B12E362 for <ima@ietfa.amsl.com>; Wed, 20 Apr 2016 11:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.492
X-Spam-Level:
X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDEy1FhVoIOK for <ima@ietfa.amsl.com>; Wed, 20 Apr 2016 11:39:41 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5631712E35D for <ima@ietf.org>; Wed, 20 Apr 2016 11:39:41 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PZ8G9LNZPC00K77M@mauve.mrochek.com> for ima@ietf.org; Wed, 20 Apr 2016 11:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1461177277; bh=pbNGA14C7QmvneCP70loTjUBwGTVrPB6UKvXsAs1GGM=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=kaPskXJFTQA3/JShwsDG9zGeIH56Ee80qVNGnv1qJV+zQr1ZEObOevRuUGiVy8WFs HIm9ATLyzpn9aYj9jlwTCWoCsiHe6WKvoVqFXbEccfhXR7KYmpyxPBVabdEExv0J4d 65tkspj+Hu9XUkBlbMMwbYLVBbjTl7pitqwFZCQk=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PYL04N2GJK00005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 20 Apr 2016 11:34:35 -0700 (PDT)
From: ned+ima@mrochek.com
Message-id: <01PZ8G9K8DGM00005M@mauve.mrochek.com>
Date: Wed, 20 Apr 2016 11:18:32 -0700
In-reply-to: "Your message dated Wed, 20 Apr 2016 12:33:43 -0400" <AECA29E7C05D83CE9736F93A@JcK-HP8200.jck.com>
References: <782609480-681267200@mail.monicals.com> <AECA29E7C05D83CE9736F93A@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ima/j-tR0etCOmYGw5BHnBsVDw1E9BE>
Cc: Alan Ayres <adayres@monicals.com>, ima@ietf.org
Subject: Re: [EAI] RFC 5335
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2016 18:39:42 -0000

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.