AD review of draft-ietf-eai-downgraded-display-01.txt

[Alexey Melnikov]

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.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Harald Alvestrand]

Alexey Melnikov wrote:

> 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?

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".

>
>>
>>     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?

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...

>
>> 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.

Concur.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[fujiwara-3]

Thank you for your comments.

> From: Alexey Melnikov <alexey.melnikov@...>
>>     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?

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

>>     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?

As commented by Harald, I wil remain as before.

>>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.

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

>>   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.

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

> 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.

I will add a sentence in Security considerations.

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

>>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.

I use one "MUST NOT" in section 3.

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

>>   [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.

I will upodate.

Regards,

--
Kazunori Fujiwara, JPRS <fujiwara@...>
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima