Subject: Re: [EAI] Review of draft-ietf-eai-simpledowngrade-03

From: Claudio Allocchio <[email-masked]>
Date: Tue, 1 May 2012 10:46:18 +0200 (CEST)

Hi Ned,

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

Correct, and I agree with your analysis.

>  You then responded with a note that essentially said signatures seem to 
> be fairly worthless in practice.

I confirm that. And that I was worried by anything which makes signatures 
and other security tools less "interesting" for users (I'm also a Service 
Provider with some million users).

> And now you appear to be saying that the realproblem is the security 
> considerations section lacks information about certain scenarios
> of concern, but I have no idea what these scenarios are.

Mybe, when I write a note at 1AM, I do not convey correctly what I want
:-)

I'm not asking at all that all possible scneraios are precisly described
and evalutated one by one.

I'm just asking that the Security Consideration cleary say that:

  - a number of security mechanisms will be broken, ALSO by this 
downgrading process, not only by EAI of course. And here you can list 
already what we know (the security section of the other downgrading 
document draft-ietf-eai-popimap-downgrade-05 makes a good job on this!).

And if you want, I'd add a general warning about effects that downgrading 
can produce in user's experience about security (see Ted's detailed 
description in his last message): less careful evaluation of received 
messages, etc.

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

And I agree with you: it does not change the scenario: it just helps a bit 
in enabling the scenario to survive, because it will further mis-educate 
users about security feelings.

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

I'm not asking that at all. See above.

> But I freely admit I may be entirely incorrect about all this because I 
> really have no idea what scenarios are that you're concerned about.

Here they are (just to re-write Ted's long message):

- this specification breaks a number of security features (which security 
people are trying to spread as much as possible);

- given the good will intention of this specification (better some 
information than nothing), users may get an even more relaxed attitute 
towards security features, getting used to pay less attention to what they 
read;

- this users' relaxed attitude can further help malicious attempts, even 
if this is going to be a very small percentage of possible attacks: an 
attacker can just start forging downgraded-like messages to be delivered 
to these few users.

Thus, in general, we should just say clearly that this specification can 
produce these effects, and that's all we can do.

Personally I'm not worried this will make the email service more insecure 
that it is already: your analsys about MIME case is perfecty correct. But 
we should just state that this adds to the problem a tiny bit, hence we 
should try to enable these transition things for the minimal 
implementation time needed, and then make them historic.

Now, speaking as a Serivce Provider, I always try to give a "ready to go" 
solution to users, whith no downgrading/transition solutions: you want 
this new service? Upgrade to what you need, or "no service". But I know 
well that I will get at least a non neglegible number of complaints about 
this yes/no solutions, and sometimes it is difficult to apply because of 
non technical reasons.

Was this message a bit clearer than the night one?

I hope so!

Does "Smoke Kills you!" stop all people from smoking? Certainly not! But 
At least I think we should continue to write it. Same position here.

Have a nice Labour's Day (for this having it!).

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R 
[email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; 
S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 May 2012 12:24:43 +0200

On 05/01/2012 12:57 AM, Ted Hardie wrote:
> For what it is worth, I still believe the signature issue is a small
> part of a more general issue:
> how do I manage user expectation of what a message should look like so
> that it is considered
> valid?

I've spoken to quite a number of people about this in the past decade,
in the context of spam, and my feeling is that "valid" usually means
either "something I was waiting for" or "something I can reply to" or a
combination of the two.

A non-EAI MUA will never be able to reply to mail from an EAI address,
so we lose on that side, no matter how hard we try. Both downgrade
documents preserve subject and attachments, so if the user was waiting
for something, both score near 100% on that side.

Arnt