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

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

On Tue, 1 May 2012, Arnt Gulbrandsen wrote:

> On 05/01/2012 11:41 AM, Claudio Allocchio wrote:
>> 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.
>
> Yes.
>
>> 5. Security Considerations
>>
>> this section is way too short and simplified, compared to the issues
>> 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?

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.

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

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

>> 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").
>
> You've made it about four times as long and hardly four times as good.

being long is a problem in a specification?

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

This does not change the need to state it.

>> 1 Overwiew
>>
>> "It may happen that a conventional IMAP or POP client (MUA) opens..."
>>                                                       ^ add the definition
>
> Do you mind if I define it as "IMAP or POP client"? That is, after all,
> the operative definition ;)

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

>> 7. IANA Considerations
>>
>> ADD the name of the correct registry!
>
> I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name.

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

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

On Wed, 2 May 2012, John Levine wrote:

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

I replied:

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

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