Re: Review of draft-ietf-eai-simpledowngrade-03

> Indeed my comments about both the "downgrading" documents are not about
> worries generated by the fact that EAI downgrading breaks security (this
> is a non issue, or a minimal issue compared to the abov general problem),
> but about the way that the "Security Considerations" sections are written.
> IMHO these sections should describe correctly (and clearly) the scenarios
> which can happen when a specification is implemented. E.g. declare clearly
> the potential problems, even if they happen in 0.1% of cases.
> If this is done, then I'm ok with the documents 

I'm sorry, but the point you're making here completely eludes me. Barry asked
for information to help him respond regarding the effects of downgrading on
three specific things: (1) Signatures, (2) Sieve, and (3) Additional attacks
facilitated by downgrading. I responded with an analysis that basically said
the first two are demonstrably nonissues and the third is badly posed. You then
responded with a note that essentially said signatures seem to be fairly
worthless in practice. And now you appear to be saying that the real problem is
the security considerations section lacks information about certain scenarios of
concern, but I have no idea what these scenarios are.

In any case, assuming these scenarios involve some sort of trickery in regards
to what headers are or aren't displayed by different clients, I'll fall back to 
my original point that given the ease with which email headers can be forged,
coupled with the uncertainty as to what client a given user might use, does
downgrading really change the the attack surface in any significant way? I
rather think it does not.

Now, I suppose you can argue that we should describe what amount to tiny
twigs on the attack tree even when there are enormous branches that are far
more accessible, but I'm going to have to disagree. The problem with devoting
time to what are effectively nonissues is that people waste their time reading