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)

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)

Arnt Gulbrandsen | 2 May 09:23 2012
Picon

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

On 05/01/2012 11:16 PM, Claudio Allocchio wrote:
> 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.

OK, what are they?

> being long is a problem in a specification?

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.

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

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

Claudio Allocchio | 2 May 10:09 2012
Picon

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


On Wed, 2 May 2012, Arnt Gulbrandsen wrote:

> On 05/01/2012 11:16 PM, Claudio Allocchio wrote:
>> 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.
>
> OK, what are they?

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?

(Continue reading)

Arnt Gulbrandsen | 2 May 10:22 2012
Picon

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

On 05/02/2012 10:09 AM, Claudio Allocchio wrote:
> On Wed, 2 May 2012, Arnt Gulbrandsen wrote:
> 
>> On 05/01/2012 11:16 PM, Claudio Allocchio wrote:
>>> 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.
>>
>> OK, what are they?
> 
> 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
Barry Leiba | 5 May 03:25 2012
Picon

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

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

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
_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Claudio Allocchio | 5 May 16:34 2012
Picon

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


On Fri, 4 May 2012, Barry Leiba wrote:

>>> 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.
>
> Oy.  Sorry: you're both being lazy.  The IANA registries are here:
> http://www.iana.org/protocols/

yes... but?

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

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.

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

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.

> Barry
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio <at> garr.it
                         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
John Levine | 2 May 06:50 2012

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

>This section should give an exaustive list of caveats, and possible 
>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
Claudio Allocchio | 2 May 09:32 2012
Picon

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


On Wed, 2 May 2012, John Levine wrote:

>> This section should give an exaustive list of caveats, and possible
>> 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.

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

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

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.

>
> R's,
> John
>
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio <at> garr.it
                         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
John R Levine | 2 May 13:52 2012

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

>>  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.
>
> this is a good short and clear way to state the problem! +1

Oh, good.

> In case, references to other Security Consideration sections of published 
> 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, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
ned+ima | 2 May 17:55 2012

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

> >>  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.
> >
> > this is a good short and clear way to state the problem! +1

> Oh, good.

> > In case, references to other Security Consideration sections of published
> > 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.

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

				Ned

Gmane