John R Levine | 1 May 01:04 2012

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

> 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 entirely agree.  At some point we (for a very general construction of 
we) will have to figure out how to show messages in a way that gets the 
message through that this message is real, but it's a very hard problem.

It certainly has nothing to do with EAI.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
ned+ima | 1 May 07:56 2012

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
(Continue reading)

Claudio Allocchio | 1 May 10:46 2012
Picon

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


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:

(Continue reading)

Claudio Allocchio | 1 May 11:41 2012
Picon

AppsDir Review of draft-ietf-eai-simpledowngrade-03

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:
(Continue reading)

Claudio Allocchio | 1 May 11:42 2012
Picon

AppsDir review of draft-ietf-eai-popimap-downgrade-05

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-popimap-downgrade-05
Title: Post-delivery Message Downgrading for Internationalized Email
        Messages
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This document is requires a major decision about 
updating/non updating RFC 5322 before it can go to publication. Once 
this is done, other minor changes are listed below and it can be 
published. Another issue to clarify/fix is its relationship with 
draft-ietf-eai-simpledowngrade-03 specification (and also in that 
document, of course, with respect to this one).

Major Issues:

3. Updating RFC 5322

(Continue reading)

Arnt Gulbrandsen | 1 May 12:24 2012
Picon

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

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
Alexey Melnikov | 1 May 21:01 2012

Re: a couple of 5738bis comments

Hi Arnt,

On 30/04/2012 15:38, Arnt Gulbrandsen wrote:
> Alexey answers me:
>>>     b enable utf8=accept
>>>     c select inbox
>>>
>> I am entirely lacking coffee today, so can you please spell out:
>> 1). what is the problem
> I see two obviously useful cases.
>
> 1. Client wants EAI.
> 2. Client doesn't.
>
> But 5738bis provides three settings.
>
> 1. Client wants EAI syntax and messages.
> 2. Client wants EAI syntax but not EAI messages
> 3. Client knows nothing about EAI.
>
> (The command sequence above provides the middle case.)
I don't think we really care about 2. Maybe we used to care when there 
were more IMAP extensions in the same document.

Remind me how is 1 different from 2?
>> 2). what change you are proposing to fix it.
> I'm not proposing. I'm wondering why the document offers three cases.
>
> I'm not saying "b enable utf8=accept" followed by "c select inbox" is
> pointless, I'm asking what its point is.
(Continue reading)

Arnt Gulbrandsen | 1 May 21:54 2012
Picon

Re: a couple of 5738bis comments

Alexey answers me:
>> 1. Client wants EAI syntax and messages.
>> 2. Client wants EAI syntax but not EAI messages
>> 3. Client knows nothing about EAI.
...
> I don't think we really care about 2. Maybe we used to care when there
> were more IMAP extensions in the same document.
> 
> Remind me how is 1 different from 2?

  a login alexey features
  b enable utf8=accept
  c select inbox ...
  d uid fetch 1:* bodystructure

If command c uses the UTF8 option, command d returns data from the real
messages. This is option 1 above.

If command c doesn't use the UTF8 option, the responses for command d
can use *"..." strings, but have to contain downgraded information. This
is option 2 above.

If option 2 isn't valuable, then I think the UTF8 option to SELECT, LIST
etc can perhaps be dropped, and the single command ENABLE UTF8=ACCEPT
turns on EAI support completely.

Arnt
Arnt Gulbrandsen | 1 May 22:44 2012
Picon

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

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?

> 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?
(Continue reading)

Claudio Allocchio | 1 May 23:16 2012
Picon

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


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 
(Continue reading)


Gmane