Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[Arnt Gulbrandsen <[e-mail]>]

On 09/19/2012 04:24 AM, Ben Campbell wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>  .
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document:  draft-ietf-eai-simpledowngrade-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
>
> Summary: This draft is mostly on the right track, but has open issues
>
> Major issues:
>
> -- I'm concerned about the security considerations related to having a mail drop modify a potentially signed message.
...

Hm, sounds like a misunderstanding. Did you understand that the 
modification happens in RAM, and that the message stored unmodified and 
has the valid signature? If not I suppose extra verbiage is needed.

The signature issue has been discussed. The answer is more or less: The 
WG expects EAI users to use EAI-capable software, and to accept partial 
failure when using software that cannot be updated.

This entire draft is draft is about damage limitation when an EAI user 
uses EAI-ignorant software (e.g. your phone, if you do your main mail 
handling on a computer but occasionally look using the phone). That 
there will be damage is expected and accepted. IMO it's unavoidable. The 
WG tries to ensure that the damage is not permanent (in the same 
example: so you can still read the mail, properly signed and addressed, 
on your computer).

FWIW, I mangled a message by hand to see what happened to a signature, 
and got an angry-looking complaint above the body text. Or maybe it was 
above the headers. Whatever.

> Minor Issues:
>
> -- It's not clear to me why this is standards track rather than informational.

I don't remember. Perhaps because it needs to update 3501.

> -- section 3, 2nd paragraph:
>
> Are there any limits on how much the size can differ from the actual delivered message? Can it be larger? Smaller? It's worth commenting on whether this could cause errors in the client. (e.g. Improper memory allocation)

An input message can be constructed to make the difference arbitrarily 
large. For instance, just add an attachment with a suggested filename of 
a million unicode snowmen, and the surrogate message will be several 
megabyte smaller than the original. Or if you know that the target 
server uses a long surrogate address format, add a million short Cc 
addresses and the surrogate will be blown up by a million long CC addresses.

I doubt that this is exploitable. You can confuse or irritate the user 
by making the client say "downloading 1.2MB" when the size before 
download was reported as 42kb, that's all. I wish all my problems were 
as small.

I'll add a comment and a reminder that the actual size is supplied along 
with the literal during download.

> -- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also mention DOWNGRADED?"
>
> Good question. It seems like they should be consistent on things like this. (This is really more a comment on that draft than this one.)

I think I've made up my mind that in this case it doesn't matter. 
Kazunori's task is complex reversible downgrade and has the Downgraded-* 
header fields, why then bother with the DOWNGRADED response code? But 
it's not my decision.

> -- Abstract should mention that this updates 3501

Really? A detail of this document updates a minor detail of that 
document, that's hardly what I would expect to see in a single-paragraph 
summary.

I know someone who likes to repeat the Subject in the first line of the 
email body text. Just in case I didn't see it the first time, I suppose.

> -- section 1:
>
> Can you more explicitly define "conventional"? I assume this means clients not supporting the relevant UTF8 capabilities? This terminology is inconsistent between this and draft-ietf-eai-popimap-downgrade.

OK.

Arnt