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 think this is already pretty clear: The texts says things like "present"
and "serve". It takes a pretty deliberate misreading to miss those words.
Moreover, stating that this "happens only in RAM" may not be correct. A server
could choose to store a downgraded version so it doesn't have to be rerendered,
for example. The point is that version isn't going to be presented to a client
that supports EAI, not that it only happens in RAM.
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.
I think that's more a matter of fact, not opinion. If your software is
incapable of presenting something, it's incapable of presenting something.
The only question is whether you get a downgraded version the software is
capable of handling or nothing. EAI allows that choice to be made by
the implementation or operationally.
> 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.
If it's exploitable it almost certainly is what I refer to as the "tiny twig on
the attack tree". That is, if there's a size-related issue there are going to
be much easier ways to exploit it than this.
I suppose some folks may believe that describing these sorts of twigs is
valuable. I disgree and believe it to be unncesssary clutter that is likely to
end up detracting from overall security.
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.
I agree it doesn't matter.
> -- 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.
Exactly right. This is a silly thing to do.
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.
The policy for EAI documents, which was agreed to by the working group and
which is now reflected in a number of RFCs, is not to put this sort of nonsense
in the abstract.
Ned