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

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