[apps-discuss] Fwd: Review of draft-ietf-eai-simpledowngrade-03

Ted Hardie <ted.ietf@gmail.com> Mon, 23 April 2012 16:23 UTC

MIME-Version: 1.0
In-Reply-To: <CA+9kkMDwOu=T+dwUvNmDdFbtEA6g__2=iB6J_m--9mX-_WNQZQ@mail.gmail.com>
References: <CA+9kkMDwOu=T+dwUvNmDdFbtEA6g__2=iB6J_m--9mX-_WNQZQ@mail.gmail.com>
Date: Mon, 23 Apr 2012 09:23:28 -0700
Message-ID: <CA+9kkMA+gwo9zxUcbb6NK5CFu3T3kUbRHr9-pH5cPtZyodHDrA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] Fwd: Review of draft-ietf-eai-simpledowngrade-03
Precedence: list

Apologies; I forgot to cc this list on the review.

regards,

Ted

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, Apr 23, 2012 at 8:57 AM
Subject: Review of draft-ietf-eai-simpledowngrade-03
To: draft-ietf-eai-simpledowngrade.all@tools.ietf.org
Cc: IESG <iesg@ietf.org>

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Ted Hardie
Review Date: April 23, 2012

Summary: I believe that the draft is almost ready for publication, but
that it cannot be progressed on the standards track because of its
impact on the security of the email messages.  I understand the
reluctance of the WG to create Experimental documents at this stage,
so I suggest Informational as a target status.

Major Issues:

The document is clear that its intent is to provide a
simple-to-implement method that provides basic means for downgrading
certain fields in a message.   A major element of its strategy is to
silently excise information which cannot be presented to the user.
This may eliminate MIME parameters (see section 2.2); it may also
eliminate any header field not explicitly treated (the subject field
and those listed in 2.1).  This, combined with the possible invalidity
of signatures for signed body parts, can significantly reduce the
amount of data available to the user for making a determination of
whether or not a message is legitimate.  Crafting a message that
appeared to have already gone through this encoding also seems
relatively easy, making it possible for a sender to provide a message
that does not have the normal complement of data for assessment by a
user.

Given this major loss of information, I do not believe that this
document describes an approach that should be placed on the standards
track; if the working group believes this to be valuable, it should be
delivered as informational.  This seems also to be a better fit for
the loose interoperablity strategy here:

"The format of the display-name is explicitly unspecified. Anything
  which tells the user what happened is good. Anything which produces
  an email address which might belong to someone else is bad."

Minor Issues:

The document does not describe how it relates to the other two options
the working group has discussed for downgrade.  I believe it should do
so in order to provide context for the choices made here.  A review of
the mailing list shows this message:
http://www.ietf.org/mail-archive/web/ima/current/msg04539.html as
kicking off the core rationale and relationship.   Some form of this
should be included in the document, possibly along with the "no
downgrade" option.

This document does not describe how the IMAP/POP downgrade choices
here would impact SIEVE script processing; I believe this represents
an assumption on when the downgrade takes place which should be made
explicit.

Nits:

The document says:

  Given an internationalized address "Fred Foo <fred@EXAMPLE.com>", an
  implementation may choose to render it e.g. as these examples:

"render" is seriously overloaded in this context.  Would "encode" work
as well here?

[apps-discuss] Fwd: Review of draft-ietf-eai-simp… Ted Hardie
Re: [apps-discuss] Review of draft-ietf-eai-simpl… Ted Hardie
Re: [apps-discuss] Fwd: Review of draft-ietf-eai-… Ned Freed
Re: [apps-discuss] Review of draft-ietf-eai-simpl… Arnt Gulbrandsen
Re: [apps-discuss] Review of draft-ietf-eai-simpl… Arnt Gulbrandsen
Re: [apps-discuss] Review of draft-ietf-eai-simpl… John Levine