Subject: [EAI] ISSUE: smtext-08 security considerations

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 24 Sep 2007 19:17:42 +0200

I'm at a loss how section 7 passed any giggle test before WGLC.

Without a thorough discussion why offering UTF8SMTP at the MX
when it won't work out at the final delivery MTA is a really
bad idea this I-D isn't ready for an IETF Last Call.  Nobody
wants *more* undeliverable mails causing misdirected bounces.

That's likely not the only missing "security consideration",
the very minumum I expect in an RFC is a honest attempt to
discuss potential security issues.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Sep 2007 15:53:17 +0200

I do not see an issue specific to EAI here.

MX paths can fail for all sorts of reasons, the combination of no 
UTF8SMTP and no downgrade is just one of them.

No issue # assigned.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 27 Sep 2007 20:10:50 +0100

>> discuss potential security issues.
Frank, if you want anything to be added I would recommend that you be 
more specific and suggest some text for inclusion.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Sep 2007 23:18:08 +0200

Alexey Melnikov wrote:
 
> if you want anything to be added I would recommend that you be 

Okay, that's fair, one suggestion, in addition to the security
considerations already covered in RFC 4592:

| The optional ALT-ADDRESS parameter allows to use unrelated
| domains in the UTF8SMTP address and the alternative address,
| i.e. the alternative domain is not guaranteed to be the IDNA
| ACE version of the IDNA UTF-8 domain in the UTF8SMTP address.
| The study of the security implications of this freedom in the
| choice of alternative addresses is one goal of the experiment
| specified in this memo.

 Frank

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2007 14:46:15 -0400

--On Thursday, 27 September, 2007 23:18 +0200 Frank Ellermann
<[email-masked]> wrote:

> Alexey Melnikov wrote:
>  
>> if you want anything to be added I would recommend that you
>> be  more specific and suggest some text for inclusion.
> 

Frank, as has been pointed out several times in the development
of the current model, there are legitimate reasons why the
domain might be different.  For example, one might imagine a
whole collection of content-translation services that would do
some of the remappings that one might want along with simple
address/ header downgrading on a commercial or service basis.
So, while a different domain might represent something one might
warn against, the implication that it is inherently bad news
--which your paragraph almost does-- is a bit too much.

Perhaps:

	The optional ALT-ADDRESS parameter allows the use of
	UTF8SMTP addresses and alternate addresses that are not
	related to each other in any obvious algorithmic way.  There
	is no requirement that the alternate local-part be, e.g., a
	translations or transliteration of the UTF8SMTP local part
	nor that the alternate domain part be the IDNA ACE version
	of the IDNA UTF-8 domain part.  The flexibility this implies
	appears to be necessary because a number of reasonable
	configuration relationships cannot easily be reflected in
	DNS or syntax relationships.  However, like all other
	in-transit transformations of message bodies (such as those
	performed by gateways), the same flexibility provides a
	potential vector for attacks.  During the experiment
	proposed in this set of documents, careful attention should
	be paid to whether the risks associated with, e.g., use of
	ALT-ADDRESS to divert messages to unexpected destinations
	are significantly more problematic and email address
	spoofing more generally.

That is a lot more words than your proposal, for which I
apologize (perhaps someone else can do better), but covers the
same basic ground and points out that there is no less problem
with the local-part (e.g., is [email-masked] related to
[email-masked] or not?).   It also avoids statements
about what the experiment is.  I would prefer to avoid that at
this point, at least without reissuing "framework" (RFC 4932),
but I think the paragraph makes the point.

     john

p.s. So that no one is surprised and to give an early
opportunity for objections (ask Harald for an Issue number if
you do): I argued on a recent editorial team call that material
that would have been been placed in RFC 4932 if we had
understood the need for it before that document was completed
should be placed in "updates RFC 4932" appendices to these
documents rather than being incorporated inline in the newer
documents.  Examples include the material in sections 3-5 of
smtpext that might better have been placed in RFC 4932, updating
the relevant sections there and security considerations material
that applies, not to a single document of the series but to
multiple documents in the collection.  That separation has no
substantive effect on the protocol specification or
explanations, but will make it much easier to re-integrate the
material into RFC 4932bis when we start on it as part of the
post-experiment process (assuming, of course, that we get there).

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Sep 2007 22:22:36 +0200

John C Klensin wrote:

> while a different domain might represent something one might

It's not necessarily bad news.  If the different domains use
the same MXs it's a sound "Return-Path" scenario.  Something
on a route from A to B doesn't work, and MTA X on this route
is forced to report an error.  At this point the A -> X part
of the rout A -> X -> B worked, and I'd hope that a NDR will
make it back from X to A.

If the envelope sender (UTF8SMTP or alt-address) is unrelated
to A, say C != A, then the NDR has to make it from X to this
unrelated C, where it might meet new trouble between X and C.

Introducing new potential sources of errors while trying to
report and fix the original problem between X and B would be
an inherently bad idea.

Of course that's a general consideration, it's no specific
problem with the UTF8SMTP "alternate envelope sender" option.

 [Your proposal]
> DNS or syntax relationships.

In theory we could recommend "same MXs", but in practice I
fear this would unnecessarily obscure the issues.  And we'd
certainly not want somebody trying to enforce this detail.

>                               However, like all other

Sounds good.

> It also avoids statements about what the experiment is.  I
> would prefer to avoid that at this point, at least without
> reissuing "framework" (RFC 4932), but I think the paragraph
> makes the point.

Yes, s/4932/4952/g :-)

> re-integrate the material into RFC 4932bis when we start on
> it as part of the post-experiment process

That's still too far away for me to think about it.  We'll
then have 2821bis, 2822upd, IDNAbis, mailto-bis, and what
else, and a different email world with EAI, DKIM, SPF, etc.
(email-arch, hutzler-spamops, 4409upd, ...).

If you're looking for more work please insert 3696bis before
4952bis, just today I needed RFC 3696 again on another list:
<http://permalink.gmane.org/gmane.ietf.message-headers/46>

 Frank

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2007 18:57:19 -0400

--On Friday, 28 September, 2007 22:22 +0200 Frank Ellermann
<[email-masked]> wrote:

>...

I'm completely overwhelmed by what is in the queue already so,
no, I'm not looking for more work.  I would probably get
motivated about 3696bis if, after the queues cleared somewhat, I
saw fairly clear consensus on the IETF list that the community
wanted a revision... perhaps wanted it enough to make the
revision a BCP.

    john