Last Call Review of draft-ietf-eai-rfc5721bis-
review-ietf-eai-rfc5721bis-secdir-lc-nir-2012-09-13-00

Request Review of draft-ietf-eai-rfc5721bis
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-09-20
Requested 2012-09-07
Other Reviews Genart Last Call review of - by Ben Campbell (diff)
Review State Completed
Reviewer Yoav Nir
Review review-ietf-eai-rfc5721bis-secdir-lc-nir-2012-09-13
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg03526.html
Review result Almost Ready
Draft last updated 2012-09-13
Review completed: 2012-09-13

Review
review-ietf-eai-rfc5721bis-secdir-lc-nir-2012-09-13

Hello,

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