From nobody Tue Apr 19 06:25:57 2016 Return-Path: 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 15C7212EC5B for ; Tue, 19 Apr 2016 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 L2_79RmHJ6Vt for ; Tue, 19 Apr 2016 06:11:32 -0700 (PDT) Received: from mx.monicals.com (mx.monicals.com [63.144.69.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C612EA7A for ; Tue, 19 Apr 2016 06:11:32 -0700 (PDT) Received: from mail.monicals.com ([172.25.1.6]) by mx.monicals.com (8.14.7/8.14.7) with ESMTP id u3JDBUd7027788 for ; Tue, 19 Apr 2016 08:11:30 -0500 X-Footer: bW9uaWNhbHMuY29t Received: from localhost ([127.0.0.1]) by mail.monicals.com for ima@ietf.org; Tue, 19 Apr 2016 08:11:30 -0500 Date: Tue, 19 Apr 2016 08:11:30 -0500 X-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.5.17 (KHTML, like Gecko) Version/9.1 Safari/601.5.17 Message-ID: <782609480-681267200@mail.monicals.com> From: Alan Ayres To: ima@ietf.org X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-WyzVAnkKl6V4JUNNjhNn" Archived-At: X-Mailman-Approved-At: Tue, 19 Apr 2016 06:25:56 -0700 Subject: [EAI] RFC 5335 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:11:42 -0000 --=-WyzVAnkKl6V4JUNNjhNn Content-Type: text/plain; charset="utf-8" From: Cindy Morgan via RT To: 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: ima@ietf.org You may also want to note that RFC 5335 was obsoleted by RFC 6532 in 2012. Best regards, Cindy On Fri Apr 08 08:14:58 2016, adayres@monicals.com 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 --=-WyzVAnkKl6V4JUNNjhNn Content-Type: text/html; charset="utf-8"


From: Cindy Morgan via RT <iesg-secretary@ietf.org>
To: <adayres@monicals.com>
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: ima@ietf.org

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, adayres@monicals.com 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



--=-WyzVAnkKl6V4JUNNjhNn-- From nobody Wed Apr 20 09:33:52 2016 Return-Path: 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 A303D12E435 for ; Wed, 20 Apr 2016 09:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no 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 EJlL0u7K9mB8 for ; Wed, 20 Apr 2016 09:33:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BB112E092 for ; Wed, 20 Apr 2016 09:33:50 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1asv4X-000Nux-1E; Wed, 20 Apr 2016 12:33:49 -0400 Date: Wed, 20 Apr 2016 12:33:43 -0400 From: John C Klensin To: Alan Ayres Message-ID: In-Reply-To: <782609480-681267200@mail.monicals.com> References: <782609480-681267200@mail.monicals.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:33:51 -0000 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 wrote: > From: Cindy Morgan via RT > To: > 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: ima@ietf.org > You may also want to note that RFC 5335 was obsoleted by RFC > 6532 in 2012. > > Best regards, > Cindy > > On Fri Apr 08 08:14:58 2016, adayres@monicals.com 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) From nobody Wed Apr 20 11:39:42 2016 Return-Path: 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 ; 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 ; 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 ; 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 (PDT) In-reply-to: "Your message dated Wed, 20 Apr 2016 12:33:43 -0400" References: <782609480-681267200@mail.monicals.com> To: John C Klensin Archived-At: Cc: Alan Ayres , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: I'm not going to comment further except to note that RFC 2311-2645 are all S/MIME specifications. From nobody Wed Apr 20 12:11:24 2016 Return-Path: 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 5D46B12E3CB for ; Wed, 20 Apr 2016 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 VC5DGtVueMaQ for ; Wed, 20 Apr 2016 12:11:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B341D12E3A2 for ; Wed, 20 Apr 2016 12:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c+OKePf8YjNoXC5H7XK08eG3vXDMQbuyGfc6Sbs0LMQ=; b=cHZTWclj7rbznbnHH3xXLnvFqVzrcFjhI8TV5XEvN0SpPTsyFxTN/Zty3aUCYNfY2pyOe5tgbWUOYoWhgfalsvmtXIbZhJHhjjk4VpXFi8WkomBpADMeqKKr4D3qAlPWp4fXIe3m6w9Ez11fOsnO+kFKIuk60kTvEDC+zWslzQk= Received: from SN1PR0301MB2045.namprd03.prod.outlook.com (10.163.226.154) by SN1PR0301MB2046.namprd03.prod.outlook.com (10.163.226.155) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 19:11:18 +0000 Received: from SN1PR0301MB2045.namprd03.prod.outlook.com ([10.163.226.154]) by SN1PR0301MB2045.namprd03.prod.outlook.com ([10.163.226.154]) with mapi id 15.01.0466.023; Wed, 20 Apr 2016 19:11:18 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: [EAI] RFC 5335 Thread-Index: AdGbN3WuV8lbbTiMT7KKKBLbHqb+DQ== Date: Wed, 20 Apr 2016 19:11:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::ae] x-ms-office365-filtering-correlation-id: 0b85842a-fa9b-45a6-2491-08d3694f8d8e x-microsoft-exchange-diagnostics: 1; SN1PR0301MB2046; 5:iTX8gV91zeizW7kJwCYlaOKv3q7G0Q40UlNKzg1T7LKn8iqUX8FBUTfs3KMbhPbhNiHaUf2d12v3/2Wz/TlxoQgS4D4BWYtXP9Ar/qVMSt6GRLNCt1ZX991kZihJLDOBtNF/z/6p9LhFMa7B8zfNx8tF4+f05WTDFBJRYiFXmUQppbFwBy9vxUtzkg5vv3eH; 24:oyz8pffuWEW32fGqmuhvDkSlsJziwdFltYoVCZMuxePWHHT/PFRxclH/6oM/ExQ/YyyuVrECO9wPaFuvLN3eNXBIKOZ65Xz5hKWatBav0Xg=; 7:Til7Nq/dkLLG0KM2LQUMYuE8XrH7OANzk7kzoX6dPMguL9m5nFKdw3x1Z+E+gTAh+7bS82XMsJQjhFtv5mxlFJpV940wRmc8+qgmHN31aWr1wdvIybBq3qKd//7LGtCdLZH875nOXe6kbMmxZhxPL7Rtkpdaj3sTC5oNRvrb8GIcAo3fO7eE6LlC52u7Dt9EbLQlVLxFudhaB9H/BRZtb0LKYltfph6xDck91dgYSU6MCmQV5UmOw8lnsop8cGAj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB2046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB2046; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB2046; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(99286002)(15975445007)(11100500001)(19580405001)(19580395003)(1720100001)(92566002)(5004730100002)(86612001)(77096005)(122556002)(2351001)(3280700002)(3660700001)(2906002)(9686002)(5640700001)(76576001)(86362001)(81166005)(74316001)(2501003)(50986999)(54356999)(15395725005)(87936001)(10090500001)(6116002)(102836003)(33656002)(5003600100002)(586003)(5005710100001)(10400500002)(10290500002)(2900100001)(4326007)(1730700002)(110136002)(1096002)(1220700001)(5002640100001)(5008740100001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB2046; H:SN1PR0301MB2045.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 19:11:18.5888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2046 Archived-At: Cc: John C Klensin , Alan Ayres Subject: Re: [EAI] RFC 5335 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:11:23 -0000 Speaking personally/unofficially: I'm unable to see the original article as it seems to be pay-to-read, howev= er I concur with John's statement. A quick search didn't find other materi= al 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 purp= oses. Without more information about the perceived problem it's hard to co= mment on it. -Shawn ---------------------------------------------------------------------- Message: 1 Date: Wed, 20 Apr 2016 12:33:43 -0400 From: John C Klensin To: Alan Ayres Cc: ima@ietf.org Subject: Re: [EAI] RFC 5335 Message-ID: Content-Type: text/plain; charset=3Dus-ascii Alan, Thanks to Cindy for forwarding this. A few comments inline below; others o= n the WG mailing list may have things to add. --On Tuesday, April 19, 2016 08:11 -0500 Alan Ayres = wrote: > From: Cindy Morgan via RT =20 > To: =20 > Sent: 4/18/2016 4:46 PM=20 > Subject: [www.ietf.org/rt #119754] RFC 5335=20 >=20 > Alan, > =20 > You have reached the IETF Secretariat, and as such, we are not=20 > qualified to answer your question. > =20 > It looks like RFC 5335 was product of the Email Address=20 > Internationalization Working Group, which concluded back in 2013.=20 > However, the mailing list for that group is still active, and you may=20 > have better luck if you try your question > there. The address for that mailing list is: ima@ietf.org =20 > You may also want to note that RFC 5335 was obsoleted by RFC > 6532 in 2012.=20 > =20 > Best regards, > Cindy > =20 > On Fri Apr 08 08:14:58 2016, adayres@monicals.com wrote:=20 >> Recently a part by iSHERIFF titled "Office 365 Security: Why you need =20 >> to be worried" came across my desk slamming Office 365. >> Per the article, a claim is made that Office 365 does not follow =20 >> current RFC standards for email headers. I can't comment on Office 365 at all and, since I've never installed and us= ed Outlook, have no firsthand information about how it handles non-ASCII ad= dressing. However, it has been my impression from earlier discussions that= the intent was to make it standards-conforming when it was upgraded to han= dle 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=20 >> unauthorized intercept, editing and the ability to resend these=20 >> messages with malicious content within the headers of the message.=20 >> As you appear to be an authority of RFC 5335, I was hoping you would=20 >> 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 t= o it has, at best, a fundamental misunderstanding about the relationships i= nvolved. 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. Th= e SMTPUTF8 work is rather carefully designed to ensure that messages with n= on-ASCII addresses (mailbox names) or headers that do not conform to the AS= CII limitations of RFC 5322 are never delivered to systems that do not supp= ort them. If those rules, described in RFC 6530 and 6531, are followed, th= en a system that lacks adequate support would never see such a message, muc= h 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 suc= h a vunerability -- the major difference between the earlier experimental w= ork and the standards track documents is that the earlier work included pro= visions for trying to rewrite addresses and messages to allow them to go th= rough 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 header= s without conforming to the standards could get themselves into all sorts o= f trouble, but that is true of email headers and transmission generally. If "iSHERIFF" thinks that there are attack vectors for implementations of t= he standards specified in RFC 6530 - 6533, it would be good if he or she wo= uld 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: ned+ima@mrochek.com To: John C Klensin Cc: Alan Ayres , ima@ietf.org Subject: Re: [EAI] RFC 5335 Message-ID: <01PZ8G9K8DGM00005M@mauve.mrochek.com> Content-Type: TEXT/PLAIN; CHARSET=3Dus-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 co= vers 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 possibl= y 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 E= AI messages without supporting the associated SMTP extension, which AFAICT = is not presently supported. Of course nothing prevents someone from attempting to send a message contai= ning 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 i= s that it makes a small subset of that garbage legal, which actually create= s a more complex security problem for the system. In any case, mail systems have to defend against invalid inputs. It has alw= ays been this way and likely always will be. Whether or not EAI is supporte= d is largely orthogonal to this. Ned P.S. No doubt it's mean of me, but I simply can't resist quoting another pa= rt of this report. It says: Microsoft MIME Doesn't Follow RFC; More Open To Malware Microsoft MIME (Multipurpose Internet Mail Extension) is an application t= hat allows for the transfer of different files through the internet. For a fi= le transfer to happen successfully both the file servers and the browsers mu= st have the same MIME versions applied. Microsoft MIME latest version follow= s the following RFC (Request For Comments) Internet Standards: RFC 2311, RFC 23= 12, 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 le= ft 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 witho= ut them, they leave Microsoft MIME vulnerable to several serious attacks whi= ch could lead to malware infestation. The following attacks have been confir= med in applications that do not follow RFC 959 and RFC 5797: 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 IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima ------------------------------ End of IMA Digest, Vol 109, Issue 2 *********************************** From nobody Wed Apr 20 12:21:54 2016 Return-Path: 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 4DF0A12E3B3 for ; Wed, 20 Apr 2016 12:21:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no 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 l_yXFDYDztHd for ; Wed, 20 Apr 2016 12:21:52 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1B35412E2E1 for ; Wed, 20 Apr 2016 12:21:52 -0700 (PDT) Received: from [10.79.2.241] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 20 Apr 2016 12:21:51 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <01PZ8G9K8DGM00005M@mauve.mrochek.com> References: <782609480-681267200@mail.monicals.com> <01PZ8G9K8DGM00005M@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X Date: Wed, 20 Apr 2016 12:21:46 -0700 To: ned+ima@mrochek.com, John C Klensin From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: Alan Ayres , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:21:53 -0000 At 11:18 AM -0700 4/20/16, ned+ima@mrochek.com wrote: > 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: 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 nobody Wed Apr 20 13:35:33 2016 Return-Path: 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 821FB12E8DD for ; Wed, 20 Apr 2016 13:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.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 pdSx0eSIgV_S for ; Wed, 20 Apr 2016 13:35:31 -0700 (PDT) Received: from mail322.linkedin.com (mail322.linkedin.com [108.174.3.122]) (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 D7A2A12E8B6 for ; Wed, 20 Apr 2016 13:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1461184529; bh=aLU82o7yjjUZC3cIeHsvDqOpCeNuLPhacWSnk2pAk4U=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=e128zKP5+NW9U/2isP4E1ucov+jxLG2v7UmsTjQuaoYJf1XtUFMqQOn/EZcleJfDe Fro9oY6qhykFEc2wY0YoM8XezIQuRQAq8psoRwFw/U5WRS7yRjaSFOAFsGEPdU7ONe dsmE7L6iZDLs1q0uJ6ohURMg3DGiwIVcV/Ij+9ow= Authentication-Results: mail322.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail322.prod.linkedin.com; iprev=pass policy.iprev="209.85.192.72"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-qg0-f72.google.com"; dkim=none (message not signed) header.d=none; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [209.85.192.72] ([209.85.192.72:36657] helo=mail-qg0-f72.google.com) by mail322.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id D1/8B-31691-118E7175; Wed, 20 Apr 2016 20:35:29 +0000 Received: by mail-qg0-f72.google.com with SMTP id t38so79336621qge.3 for ; Wed, 20 Apr 2016 13:35:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aLU82o7yjjUZC3cIeHsvDqOpCeNuLPhacWSnk2pAk4U=; b=N54aoH/Invi259JPTdUob6HHqguWvEKVqgTzrA6vB2JLchaDo5i2kvwO4yAUZMze/9 RvDTUUrJG/SqLeROOINkgaQPR1Z4uwxEcwInI4+OPu7khTFZOPY6xLmcjX3HA9TXm1Dx 5qUJZgC71ZQW6OIq0hbd+UmiruptxtGRsDA+m2fgkm4DsvDbnEQVhPDkL7sbPLorp8gR VMI4qDHGuDmuoGiMfYIqHdglPArF1Shq5/JLoa9dW3KT3OiZSnjNA1X7gt9ZL6toG1hY ZTtbXEb209Uc6zttmdyEkl4L0QWo8w7eaExb4bt4sJ5aTM8y6wTyXhXRAveyGuZOsMyx N6kQ== X-Gm-Message-State: AOPr4FWCYe7RpR9e9mbOdQ3QVHenKy/BHglT1gBcFciuZKCU8v1740nHIwouoRM7WK14cJduCw+8aQALOdpWanWHCpMUwOEGpayUY8ioXVl0rinoF+AjbbaKYMsjrfj+A06Bq7Cvbj8rTmOxQCXL25qEmQ== X-Received: by 10.194.6.225 with SMTP id e1mr11173934wja.152.1461184529328; Wed, 20 Apr 2016 13:35:29 -0700 (PDT) X-Received: by 10.194.6.225 with SMTP id e1mr11173918wja.152.1461184529093; Wed, 20 Apr 2016 13:35:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.84.99 with HTTP; Wed, 20 Apr 2016 13:35:09 -0700 (PDT) In-Reply-To: References: <782609480-681267200@mail.monicals.com> <01PZ8G9K8DGM00005M@mauve.mrochek.com> From: Franck Martin Date: Wed, 20 Apr 2016 13:35:09 -0700 Message-ID: To: Randall Gellens Content-Type: multipart/alternative; boundary=047d7b5d2bfccf052e0530f088d0 Archived-At: Cc: John C Klensin , Alan Ayres , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 20:35:32 -0000 --047d7b5d2bfccf052e0530f088d0 Content-Type: text/plain; charset=UTF-8 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 wrote: > At 11:18 AM -0700 4/20/16, ned+ima@mrochek.com wrote: > > 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: >> > > 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 > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > --047d7b5d2bfccf052e0530f088d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking personally. When I tested EAI.

MUAs tends to not care about the format of the local part. It seems develo= pers just take the string as is based on char boundaries found in the RFC53= 22.From and other places. In most places in the code, it does not matter wh= at the local part is.

So, I think you would have l= ittle 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.

Th= ings may break because the difficulty is in handling the mailbox.

Also, very few people use EAI mailboxes. So an EAI sender i= s usually a strong positive signal for SPAM.=C2=A0

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


=


<= br>
On Wed, Apr 20, 2016 at 12:21 PM, Randall Gel= lens <rg+ietf@randy.pensive.org> wrote:
At 11:18 AM -0700 4/20/16, ned+ima@mrochek.com= wrote:

=C2=A0FWIW, I dug up the actual report, which is available for download her= e:

=C2=A0http://windowsitpro.com/isheriff/office-3= 65-security

=C2=A0The relevant part of the report appears to be this paragraph:

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


=C2=A0 =C2=A0ASCII characters have been exonerated and
=C2=A0 =C2=A0exploited worldwide.

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

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


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima

--047d7b5d2bfccf052e0530f088d0--