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

From: Claudio Allocchio <[email-masked]> (by way of S Moonesamy <[email-masked]>)
Date: Tue, 01 May 2012 02:41:32 -0700

Hello all,

I have been selected as the Applications Area Directorate co-reviewer 
for this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-eai-simpledowngrade-03
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary:

This specification needs some revision before it can be published. 
Some of them are just clarifications and better text, but in the case 
of the Security Considerations section, it might even need a 
revision, set of suggestions, from the Security area folks, in order 
to find the best possible way to explain involved risks.

I also suggest further thinking about the "Proposed Standards" track 
publication. I do see a good number of pros in doing this, but I'm 
not confident this is the completely correct way to go.

Major Issues:

2.3 Subject

adding or non adding a "DOWNGRADED" or equivalent to the subject is a 
major decision which also impacts on the way the security failure 
which are introduced by this specification are perceived by the user. 
This issue shall be fixed and a decision taken ASAP, in order to publish this.

5. Security Considerations

this section is way too short and simplified, compared to the issues 
that this specification introduces against secure e-mail mechanisms.

This section should give an exaustive list of caveats, and possible 
actions in various cases, in order to make clear that this 
specification breaks explicilty most of the existing security anchors 
where users should rely nowadays. It should also list that, while it 
is clear that in most of the cases where downgrading and/or 
gatewaying is involved, possible security leaks are introduced, and 
user's security mechanisms become invalid. "as is" is not enough.

  Minor Issues:

Abstract:

given the quite invasive action on messages presentation that such a 
specification describes, such a short and "optimistic" abstract is, 
IMHO, misleading. At least insert a sentence to describe the 
scenario, and what this specification is trying to accomplish, what 
problems it tries to solve, and what issues are left open and 
voluntarily not solved here.

1 Overview:

I disagree on the way the overview present "phylosophically" the 
problem to the reader. This is a technical specification intended for 
Standards Track, not an informational document. Thus, it should not 
focus on the way implementerss spend their time, os users' 
behaviours. It should state the problem and the proposed solutions: (dot)!

Here is my suggested version of this paragraph:

---

1. Overview

It may happen that a conventional IMAP or POP client opens a mailbox 
containing internationalized messages, or even attempt to read 
internationalized messages, for instance when a user has both 
internationalized and conventional MUAs.

When this mismatched sitation happens, various strategies are possible:

  a) the server can hide the existence of such messages entirely, but
     doing that can be both tricky to implement and gives a false mailbox
     status to the user;

  b) the server attempts to present at least some information about these
     messages to the user. It shall be clear that what the user is being
     presented is not the original message, and information is dropped;

  c) the server does nothing, possibly creating problems to the client, and
     providing a bad user's experience.

This document specify a way to implement strategy b), which enables 
the best compromise between a) and c), and promotes a simple to 
implement solution which conveys a better-than-nothing information 
service to the user. Accuracy of information and Security featues of 
the message will, however, not be preserved, and users should rely on 
an internationalised client as much as possible.

The server is assumed to be internationalized internally. When it
needs to present an internationalized message to a conventional
client, it synthesizes a conventional message containing most of the
information and presents that (the "synthetic message").

----

2.1 Email addresses

At lease one sentence clearly stating that this will make impossible 
to reply to such a synthetic message should be present here. Too 
obvious? no... never suppouse that.

Nits:

1 Overwiew

"It may happen that a conventional IMAP or POP client (MUA) opens..."
                                                       ^ add the definition

I suggest coherent use also in other parts of the specification.

6. Acknowledgments

well... clean it up from the call, before publishing!

7. IANA Considerations

ADD the name of the correct registry!

----------------------------

Ok... now I can go and read my co-reviewer report :-)

------------------------------------------------------------------------------
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 22:44:07 +0200

On 05/01/2012 11:41 AM, Claudio Allocchio wrote:
> major decision which also impacts on the way the security failure which
> are introduced by this specification are perceived by the user. This
> issue shall be fixed and a decision taken ASAP, in order to publish this.

Yes.

> that this specification introduces against secure e-mail mechanisms.

As far as I can tell it introduces no issues at all.

Think about it: How would a program verify a signature when it cannot
parse the signature's owner's address? Now downgrade the signature's
owner's address, using any algorithm you can think of. What new issue
has been introduced?

> actions in various cases, in order to make clear that this specification
> breaks explicilty most of the existing security anchors where users
> should rely nowadays.

Duck that. You're just pointing out something that's easily pointed out.
AFAICT it's not an issue either I or any downgrade implementer can do
anything about, so why does it deserve any text?

> IMHO, misleading. At least insert a sentence to describe the scenario,
> and what this specification is trying to accomplish, what problems it
> tries to solve, and what issues are left open and voluntarily not solved
> here.
> 
> 1 Overview:
> 
> I disagree on the way the overview present "phylosophically" the problem
> to the reader. This is a technical specification intended for Standards
> Track, not an informational document. Thus, it should not focus on the
> way implementerss spend their time, os users' behaviours. It should
> state the problem and the proposed solutions: (dot)!
> 
> This document specify a way to implement strategy b), which enables the
> best compromise between a) and c), and promotes a simple to implement
> solution which conveys a better-than-nothing information service to the
> user. Accuracy of information and Security featues of the message will,
> however, not be preserved, and users should rely on an internationalised
> client as much as possible.
> 

You've made it about four times as long and hardly four times as good.

> 2.1 Email addresses
> 
> At lease one sentence clearly stating that this will make impossible to
> reply to such a synthetic message should be present here. Too obvious?
> no... never suppouse that.

It's not obvious, it's wrong ;) Nothing is made impossible, it was
impossible to start with.

> "It may happen that a conventional IMAP or POP client (MUA) opens..."

Do you mind if I define it as "IMAP or POP client"? That is, after all,
the operative definition ;)

> ADD the name of the correct registry!

I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 1 May 2012 23:16:37 +0200 (CEST)

> owner's address, using any algorithm you can think of. What new issue

as I already clarified in other discussions on these lists, I'm not 
talking about the signatures and other features. I'm talking about 
including a Security consideration section which describes clearly which 
features can be broken, and just warns about this. I also suggested as 
example the security considerations section of 
draft-ietf-eai-popimap-downgrade-05. See my discussions with Ned and 
others.

> anything about, so why does it deserve any text?

warning implementers that these problems exists, IMHO, is never useless.

> You've made it about four times as long and hardly four times as good.

being long is a problem in a specification?

> impossible to start with.

This does not change the need to state it.

> the operative definition ;)

it's a nit... it's up to editors :-)

>
> Arnt
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 May 2012 23:23:05 +0200

Hm.

A possibly relevant point is that this is a document for people who
maintain an IMAP or POP server and have extended it to support EAI. This
implies that the readers know several of RFCs 1939, 3501, 5721, 5738,
6530 and 6531 well. Comprehension to these people is vital,
comprehension to others is nice to have but essentially beside the point.

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 1 May 2012 23:32:06 +0200 (CEST)

> comprehension to others is nice to have but essentially beside the point.

it seems you have a bigger consideration than me on implementers knowledge 
about the global environment they're putting their product to live wihin 
:-)

... I've seen so many bad or wrong implmentations of e-mail protocol 
specifications in the last 25 years that I prefer to repeat "well known" 
things ;-) But this is just my approach, and of course a "sggestion", not 
a "MUST".

---

From: [email-masked]
Date: Tue, 01 May 2012 19:06:49 -0700 (PDT)

> owner's address, using any algorithm you can think of. What new issue

That's certainly true for any mechanism that verifies signatures using
addresses. It also points out additional work EAI needs to do to deal with the
use of EAI addresses in S/MIME and elsewhere. And since we cannot predict how
that will go, it is pointless to try and address any potential issues those
standards have with EAI or downgrading in any present specification.

Now, there may be other security mechanisms out there that interact with EAI in
interesting ways. Not to put too fine point on it, but that's their problem to
solve, not ours.

> anything about, so why does it deserve any text?

Security considerations do need to cover the issues that cannot be addressed.
That said, all that's really needed here is a statement to the effect that
downgrading may removes addresse information that may be critical to properly
assessing the validity or invalidity of a message. 

I see absolutely no point in getting into a bunch of what-ifs. If we do we'll
end up with a 20 page security considerations section that nobody, myself
included, will bother to read.

> You've made it about four times as long and hardly four times as good.

I'm afraid I have to agree. I see nothing wrong with the current text.

> impossible to start with.

While I agree, perhaps a statement to the effect that an EAI address is
inherently unusable by an non-EAI-client and this does nothing to change that
would be in order. (There are potential schemes involving encoding that
could be used to address that, but we have avoided them - I think for
good reason.)

				Ned

---

From: "John Levine" <[email-masked]>
Date: 2 May 2012 04:50:02 -0000

>actions in various cases, ...

I suppose we could add something like this:

  MUAs that attempt to validate message signatures such as DKIM or
  S/MIME will often be unable to do so, since the downgrade
  modifications will often break the signatures.  Users should upgrade
  to an EAI-capable MUA if they wish to continue doing signature
  validation in the MUA.

To echo Ned, there's a bazillion ways that messages are validated at
various stages in the delivery process, and nobody could possibly
enumerate what they all are or exactly how downgrading might break
them.  Signatures break already due to random mutations in transit,
and a few more broken signatures don't present any new threats.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 May 2012 09:23:31 +0200

On 05/01/2012 11:16 PM, Claudio Allocchio wrote:
> features can be broken, and just warns about this.

OK, what are they?

Yes.

If you sort the IMAP extension RFCs (just to take a reasonably sized
corpus) by length, you've more or less also sorted them by deployment.
The correlation isn't 1.0. But it's much closer to 1 than to -1.

> This does not change the need to state it.

Do you really think that someone who has written an IMAP or POP server
and extended it to support EAI needs to be told that EAI extends email
addresses incompatibly?

Arnt

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 2 May 2012 09:32:10 +0200 (CEST)

>  to an EAI-capable MUA if they wish to continue doing signature

this is a good short and clear way to state the problem! +1

> and a few more broken signatures don't present any new threats.

True: there is no new threats, there is just "yet another way to break the 
mechanism"

In case, references to other Security Consideration sections of published 
RFCs where these thrats are already described, could also be nice to have.

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 2 May 2012 09:45:41 +0200 (CEST)

> assessing the validity or invalidity of a message.

Sure. See John's suggestion.

> included, will bother to read.

maybe I like to read a lot... :-) but referencing other specification 
where this has already described can be enough, too.

> I'm afraid I have to agree. I see nothing wrong with the current text.

well, here is -1...

again I like to read a lot... but what's wrong is being descriptive?

ha ok... I see... I did like to write:

  $ directory/date/size/protection/owner/group *.txt

instead of

  claudio% ls -la *.txt

:-) it's my old bias and fault :-)

But... I listed it as a "Minor Issue", so...

> would be in order.

another +1

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 2 May 2012 10:09:45 +0200 (CEST)

>> features can be broken, and just warns about this.

please read ALL replies before re-posting. Digesting information helps in 
non real time discussions like those using ML:

>  to an EAI-capable MUA if they wish to continue doing signature

I replied:

is this ok for you, too?

>> being long is a problem in a specification?

well, this is your opinion, were you probably then write the code 
yourself out of the specification, or suppouse that all implementers 
belong to the IETF world, etc.. I'm afrid I live in a different world 
where programmers sometine do not even know what a "scoket()" call does 
internally and why.

But, this is an off topic for now, is it?

> and extended it to support EAI needs to be told that EAI extends email

yes, and see above why. and it does not harm anybody.

:-)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 May 2012 10:22:12 +0200

On 05/02/2012 10:09 AM, Claudio Allocchio wrote:
> please read ALL replies before re-posting. Digesting information helps
> in non real time discussions like those using ML:

When I uploaded -04 at 9:50, I had read all the mail that had arrived
until 9:30.

Specifically regarding the security problems, I've seen that signatures
can be invalid, which is in the draft, and nothing else that's concrete
enough to add to the draft. I'm sorry if I've overlooked anything.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 May 2012 10:29:55 +0200

> interesting ways. Not to put too fine point on it, but that's their problem to

I think I'm willing to mention any such problem, probably without much
detail.

But I resent being told that I should go looking for problems. Anyone
who wants me to mention a problem has to tell me what the problem is,
without handwaving.

Hm.

I tried rewording the first paragraph of the security considerations. As
I see it, it's neither better nor worse than before. But maybe others
like it more.

> could be used to address that, but we have avoided them - I think for

It's water under the bridge. This is not the time to reconsider basic
EAI design choices.

Arnt

---

From: "John R Levine" <[email-masked]>
Date: 2 May 2012 07:52:37 -0400

> this is a good short and clear way to state the problem! +1

Oh, good.

> RFCs where these thrats are already described, could also be nice to have.

Perhaps I'm overly grumpy, but it doesn't seem like a good use of anyone's 
time to try to make a list of every RFC that mentions a security scheme 
that someone might use in e-mail.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: [email-masked]
Date: Wed, 02 May 2012 08:55:48 -0700 (PDT)

> that someone might use in e-mail.

If this is "overly grumpy" then it's a condition I share.

				Ned

---

From: [email-masked]
Date: Thu, 03 May 2012 11:44:27 -0700 (PDT)

> ...

> who wants me to mention a problem has to tell me what the problem is,

I completely understand, and agree. If specifics are desired, someone needs to
volunteer text.

> ...

> It's water under the bridge. This is not the time to reconsider basic

Of course. I was only making a side comment on what might have been, but isn't
and isn't going to be.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 May 2012 21:25:03 -0400

> I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name.

Oy.  Sorry: you're both being lazy.  The IANA registries are here:
http://www.iana.org/protocols/

One can (and should) look up the registry, and use the correct name,
without guessing.
That said, Claudio didn't look it up either, and as it turns out, Arnt (1)
did use the correct name and (2) between the correct name and the reference
to the creating RFC, specified it entirely adequately for IANA to
understand it.

In other words, the IANA section is fine.

Barry

---

From: Claudio Allocchio <[email-masked]>
Date: Sat, 5 May 2012 16:34:01 +0200 (CEST)

> http://www.iana.org/protocols/

yes... but?

> One can (and should) look up the registry, and use the correct name,

that's why I added my Nits note.

> That said, Claudio didn't look it up either, and as it turns out, Arnt (1)

True, I did not loked at it.

> In other words, the IANA section is fine.

that why "(RFC editor: Please remove this paragraph. I can't remember the 
URL  of the registry, but it's the one specified in RFC 5530.)" ?

;-)

but as I said, it's a Nit.