Subject: [EAI] AD review of draft-ietf-eai-downgraded-display-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 29 Aug 2009 21:46:13 +0100

Hi,
Below is my review of the document. I think all issues I found are
minor, so I can be convinced that some suggested changes are not needed.

>
>     3. Consideration of displaying downgraded message
>
>
>   The following way is to remove "Downgraded-" from the decoded
>   "Downgraded-" header fields' name and remove the corresponding header
>   field at the same time.

This sentence doesn't read well, I am not quite sure what it is trying
to convey. Is it just saying that the proper procedure is described in
the next section?

>
>     4. Displaying downgraded message
>
>   Step 4:   Compare the output of Step 3 and the original header
>      fields.  If the same header fields exist for the output of Step 3
>      and the original header fields, remove the same header fields from
>      the original header fields.

I think the last part "remove the same header fields ..." can be worded
in a better way.
I suppose if the two [sets of] headers match, then either one can be
removed?

>This step outputs the original header
>      fields which is modified by this step 4.  Before this comparison,
>      a canonicalization described below is useful.

I think the canonicalization described below this text should be 
required. But I don't have a strong feeling about that.

>   Step 5:   Decode MIME encoded header fields and MIME body part header
>      fields according to [RFC2047] and [RFC2231].

I think this should say "Decode all *other* ...", i.e. that you already
dealt with address related header fields in previous steps.

The Security Considerations section says:

>    While displaying downgraded message changes the header fields of the
>    message and it may lose the original information, MUAs should have a
>    function to read the original received message (with/without MIME
>    decoding).

I am thinking that it might be a good idea to recommend that UIs can
emphasize when original and Downgraded- headers don't match.
If EAI downgrade gets deployed, I am sure new sorts of scams
will take advantage of 2 ways to represent information.

>9.  Normative References

[...]

>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119, March 1997.

I don't think the document is using any RFC 2119 keywords. Either it 
should, or this reference should be deleted.

>   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
>              October 2008.
>
>   [RFC5336]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
>              Email Addresses", RFC 5336, September 2008.
>
>   [RFC5337]  Newman, C. and A. Melnikov, "Internationalized Delivery
>              Status and Disposition Notifications", RFC 5337,
>              September 2008.

I think these 3 references should be Informative.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 30 Aug 2009 08:28:55 +0200

> to convey. Is it just saying that the proper procedure is described in
I think that's what it is trying to say. "The proper procedure is to 
remove.... at the same time, as described in the next section".
> I suppose if the two [sets of] headers match, then either one can be
No - you are comparing:

Downgrade(Downgraded-From: with the Downgraded- string removed)
with the "From" header.

If they match, you replace From with (Downgraded-From: with the 
Downgraded- string removed).

So if you have a header containing:

From: <ascii>
Downgraded-From: <Unicode <ascii>>

you want the header to end up containing

From: <Unicode <ascii>>

The example exists in the appendix.

Note - I do think the comparision algorithm should also be performed for 
the headers replaced in step 6 - the attack using different information 
in Downgraded-* can be done against any field, not just the 
email-address-containing ones. Missed this earlier somehow...
> I think these 3 references should be Informative.
Concur.

---

From: [email-masked]
Date: Mon, 31 Aug 2009 20:58:52 +0900 (JST)

Thank you for your comments.

> From: Alexey Melnikov <[email-masked]>

This sentence tried to introduce next section.
I will remove it.

> I suppose if the two [sets of] headers match, then either one can be

As commented by Harald, I wil remain as before.

> required. But I don't have a strong feeling about that.

I will rewrite this as 
  "Before this comparison, canonicalize each header field described below."

> dealt with address related header fields in previous steps.

I will rewrite this as 
  "Decode all other MIME encoded header fields and MIME body part header fields"

> will take advantage of 2 ways to represent information.

I will add a sentence in Security considerations.

  "MUAs can emphasize Downgraded header fields which don't match in
   step 4 of section 4."

> should, or this reference should be deleted.

I use one "MUST NOT" in section 3.

  "Although it is very easy, it MUST NOT be used because of the following reasons."

> I think these 3 references should be Informative.

I will upodate.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>