[secdir] SECDIR review of draft-ietf-eai-rfc5721bis-07

Yoav Nir <ynir@checkpoint.com> Wed, 12 September 2012 20:49 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D701821F857A; Wed, 12 Sep 2012 13:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LTX89EO79-pV; Wed, 12 Sep 2012 13:49:24 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id 766EC21F8574; Wed, 12 Sep 2012 13:49:23 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com []) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q8CKnKmd016098; Wed, 12 Sep 2012 23:49:20 +0300
X-CheckPoint: {5050F519-12-1B221DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Wed, 12 Sep 2012 23:49:18 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>, "draft-ietf-eai-rfc5721bis.all@tools.ietf.org" <draft-ietf-eai-rfc5721bis.all@tools.ietf.org>
Date: Wed, 12 Sep 2012 23:48:30 +0300
Thread-Topic: SECDIR review of draft-ietf-eai-rfc5721bis-07
Thread-Index: Ac2RJ/gAOiefXN7WRX+vZ/FKxkTrUQ==
Message-ID: <D7D94AA4-1F7F-448C-8957-2115A2DFF627@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SECDIR review of draft-ietf-eai-rfc5721bis-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2012 20:49:25 -0000


Summary: the document is almost ready.

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is a standards track version of RFC 5721, which was experimental.

It introduces two capabilities for POP3: UTF8, which indicates support for, well, UTF8 in user names, passwords and other fields, and LANG which allows the client to set the localization used by the server for human-readable responses.

The security considerations section points to the sections of other RFCs for the security considerations for UTF-8 and SASLPrep. That's a good thing IMO. It also discusses an information disclosure issue, where the response to a "LANG *" command shows an eavesdropper the preferred language (and by extension - nationality) of the user. The section advises that servers be configured to prevent this disclosure, but does not specify how that can be accomplished.

The section goes on to discuss a MitM attacker injecting a LANG command into the stream, but does not discuss a similar attack for the UTF-8 command. That is probably OK, because it does not lead to any useful attack.

Two more issues require a better explanation IMO:

The draft says that STLS MUST NOT be used after the UTF8 command. It does not say why, and I think it should.

Section 2.1 requires the maildrop to run a conversion of data to UTF-8 when the client supports it. I'm wondering if this can be exploited. Suppose we have a spam filter that works only with ASCII and UTF-8. So the spammer can send a message that is encoded in something else (EBCDIC?) that will bypass the filter. Before this extension, the client would not be able to parse this, but now, it gets converted to UTF-8 in the maildrop, and the spam gets delivered after having bypassed the spam filter.

So I think the authors should address these three minor issues, and then the document will be ready:
 (1) How do you protect against disclosure of user preferred language?
 (2) Why not STLS after UTF8?
 (3) Why attacks on the converter, or subverting it to bypass filtering is not an issue (or maybe that it is)