Thanks for the response--comments inline:
On Sep 19, 2012, at 10:18 AM, Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
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.
I make no assumptions about whether the modification is persistent in the mail
drop. The message as delivered to the client, which is where the end user
actually reads it, is modified.
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.
My point is that I believe the potential issues caused by the modification of
signed content should be covered in more depth. You mention the problem, which
is good. I'm not proposing normative guidance, but there's a lot an
implementor and deployer should think before breaking signed content.
For example, could they strip signatures? Put in warnings that explain the
reason a signature cannot be verified? Verify locally and resign the modified
version (along with a statement about what happened)? Ignore the problem
because their users never do S/MIME anyway? Even if the draft offers no
answers, I think it needs to offer more guidance about issues that the reader
needs to think about and draw conclusions from.
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.
Ah, that's a better explanation than I've seen so far :-)
-- 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.
Thanks--It's been a while since I worried about IMAP protocol details. The fact
that the actual downloaded content size is expressed elsewhere makes this less
of a concern. (And adding the proposed reminder would help other's avoid the
same mistake :-) )
-- "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.
Do you consider the open issue called out in the draft to be resolved, then?
OTOH, this highlights a concern I didn't think about when reviewing the other
draft, which is a user agent unaware of the UTF8 updates is unlikely to present
new, unknown headers to the end user. I don't know if the error code is more
likely to be presented. (I will comment on that in the thread specific to that
draft.)
-- 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.
It's standard RFC editor procedure. The abstract is often presented separate
from the rest of the draft, and the draft headers.
[...]