headers
Claudio Allocchio | 1 May 2012 11:41
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)

Permalink | Reply |
headers
Arnt Gulbrandsen | 1 May 2012 22:44
Picon
Favicon
Gravatar

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)

Permalink | Reply |
headers
Claudio Allocchio | 1 May 2012 23:16
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)

Permalink | Reply |
headers
Arnt Gulbrandsen | 2 May 2012 09:23
Picon
Favicon
Gravatar

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)

Permalink | Reply |
headers
Claudio Allocchio | 2 May 2012 10:09
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)

Permalink | Reply |
headers
Arnt Gulbrandsen | 2 May 2012 10:22
Picon
Favicon
Gravatar

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
Permalink | Reply |
headers
Arnt Gulbrandsen | 1 May 2012 23:23
Picon
Favicon
Gravatar

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

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
Permalink | Reply |
headers
Claudio Allocchio | 1 May 2012 23:32
Picon

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


On Tue, 1 May 2012, Arnt Gulbrandsen wrote:

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

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

------------------------------------------------------------------------------
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
Permalink | Reply |
headers
ned+ima | 2 May 2012 04:06

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?

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

Permalink | Reply |
headers
Claudio Allocchio | 2 May 2012 09:45
Picon

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


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

Sure. See John's suggestion.

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

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

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

Permalink | Reply |
headers
Arnt Gulbrandsen | 2 May 2012 10:29
Picon
Favicon
Gravatar

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

Ned Freed answers me:
>> > 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?
> 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.

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.

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

Hm.

I tried rewording the first paragraph of the security considerations. As
(Continue reading)

Permalink | Reply |
headers
ned+ima | 3 May 2012 20:44

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

> ...

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

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

> ...

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

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

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

				Ned
Permalink | Reply |
headers
Barry Leiba | 5 May 2012 03:25
Picon
Favicon
Gravatar

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
Permalink | Reply |
headers
Claudio Allocchio | 5 May 2012 16:34
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
Permalink | Reply |
headers
John Levine | 2 May 2012 06:50

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
Permalink | Reply |
headers
Claudio Allocchio | 2 May 2012 09:32
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
Permalink | Reply |
headers
John R Levine | 2 May 2012 13:52

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.
Permalink | Reply |
headers
ned+ima | 2 May 2012 17:55

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
Permalink | Reply |

Gmane