Subject: Re: [EAI] Re: No issue # Re: ISSUE: smtext-08 security considerations

From: SM <[email-masked]>
Date: Mon, 01 Oct 2007 14:52:28 -0700

At 11:46 28-09-2007, John C Klensin wrote:
>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.

Once we know that the server will  accept the 
UTF8SMTP address and then downgrade to the 
alternative address, we can use that  behavior to 
relay mail to third parties. e.g:

mail.example.com server is listed as a MX for 
example.com.  Although the server supports 
UTF8SMTP, mail for example.com will be downgraded 
as that that domain doesn't support 
UTF8SMTP.  mail.example.com is not a MX for 
example.org.  The mail transaction is as follows:

  MAIL FROM:<[email-masked]>
  RCPT TO:<[email-masked]> alt-address=<[email-masked]>

The message is downgraded and sent to 
[email-masked].  mail.example.com can be used 
to send mail to example.org addresses or any other address.

>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

The difference between restricting the 
alt-address to the local-part and the current 
specifications is that the problem is contained 
within the domain.  If there is a significant 
level of abuse, people will start putting in their own restrictions.

Regards,
-sm 

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2007 09:22:40 -0400

--On Monday, 01 October, 2007 14:52 -0700 SM <[email-masked]>
wrote:

>> FrÃ©dÃ©[email-masked] or not?).   It also avoids
>> statements
> 
> The difference between restricting the alt-address to the
> local-part and the current specifications is that the problem
> is contained within the domain.  If there is a significant

This works fine as long as the user controls the domain, and
domain records, of the relevant domain server.   That may not
always be the case.   Example (somewhat more realistic than
using example.whatever but should not appear in the document);

Suppose José receives his mail at hooya.com.  Suppose that
Hoo!ya has announced that they will turn on support for i18email
any day now and encourages people to sign up for utf8smtp
aliases so that such mail can be delivered to their standard
mailboxes once the facility is, in fact, turned on.  However,
they own all of their MXs, the DNS records are not under José's
control, and they announce that they have no intention of
supporting downgrading.   Now, this
preannouncement-and-get-signups plan is mildly dumb.
Technically, one might suggest that only a yahoo (sic) would
come up with it.  But it has several advantages as a marketing
ploy.

So, José follows instructions and now has two addresses,
[email-masked] and the new [email-masked].  Until the
transition is actually made, i18n mail sent to _either_ address
will bounce, but he doesn't know when the transition will occur.

Being clever, but wanting to get people used to using the
[email-masked] address, he signs up for a
forwarding/downgrading account with downgrades-are-us.co.mx.
Now he tells people to use the address field (and uses it as the
backward-pointing address on mail he sends out if Hoo!ya will
let him):
     [email-masked]; ALT-ADDRESS="[email-masked]"

The domains are different.   The local parts are different.  The
mail will eventually end up in the "[email-masked]" mailbox, but
downgraded, a service which hooya.com and its MXs are unwilling
to provide.

FWIW, I consider scenarios like this one to be likely,
especially if one or more of the large public mail providers
implement utf8smtp slowly and in a half-hearted way.   If that
occurs, strong proof of concept for email i18n -- strong enough
to persuade them to deploy high-quality implementations -- is
likely to _require_ that sites like the hypothetical
"downgrades-are-us.mx" to come into being.  It might even be a
business opportunity for a fee for service activity.

If I'm right, excluding the possibility in the name of security,
especially given how easily email addresses are spoofed and
diverted in other ways, come pretty close to shooting ourselves
in the foot.

      john

---

From: SM <[email-masked]>
Date: Wed, 03 Oct 2007 14:27:13 -0700

Hi John,
At 06:22 03-10-2007, John C Klensin wrote:
>Suppose JosÃ© receives his mail at hooya.com.  Suppose that
>they own all of their MXs, the DNS records are not under JosÃ©'s

I see the rationale for this feature.

>downgraded, a service which hooya.com and its MXs are unwilling

The idea of not having a tie between the two 
addresses has merit as it helps to in cases as the one you explained above.

>implement utf8smtp slowly and in a half-hearted way.   If that

Agreed.

>business opportunity for a fee for service activity.

Definitely. :-)

>diverted in other ways, come pretty close to shooting ourselves

I was looking at the problem from the another 
angle which includes that possibility.  I think 
that the text you proposed would be a useful addition to the draft.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2007 18:52:47 -0400

--On Wednesday, 03 October, 2007 14:27 -0700 SM
<[email-masked]> wrote:

>> Hoo!ya has announced that they will turn on support for
>> i18email any day now and encourages people to sign up for
>...
>> The domains are different.   The local parts are different.
>> The mail will eventually end up in the "[email-masked]"
>> mailbox, but downgraded, a service which hooya.com and its
>> MXs are unwilling to provide.
> 
> The idea of not having a tie between the two addresses has
> merit as it helps to in cases as the one you explained above.
>...

Now that I've convinced SM, I note that the particular example I
gave would not work with the present versions of smtpext and
downgrade, since it requires either that:

	* the message be picked up by an MX intermediary that is
	UTF8SMTP-capable and that has enough external knowledge
	to relay the message to "downgrades-are-us.mx" rather
	than rejecting (or downgrading itself) when it discovers
	that the better-preference MX hosts don't yet support
	the extension.
	
	* we permit non-ASCII addresses in the ALT-ADDRESS field.

The latter is not possible with the current spec.  The former is
possible, but requires external knowledge (e.g., a separate
table or database) and does not depend on ALT-ADDRESS at all.  

The combination suggests an entirely different mechanism for
specifying an alternate address or mail routing, but I think it
is far too late to pursue it for the current round of documents.
If we discover, in practice and as experiments are performed,
that downgrading is not sufficiently supported and is necessary
to make things work smoothly, we might want to come back to this.

I do believe that there are examples that are somewhat similar
to this that require different domains than the domain in the
primary address or domains that are not under the direct control
of the MX host.  One would arise with an example discussed very
early in this process.  

Suppose a user speaks and reads only, say, Klingon.  She might
then have
    [email-masked] 
      ALT-ADDRESS="[email-masked]"
The system at the latter address would accept a downgraded
message, translate it (content as well as headers) to Klingon,
and then forward the result to an appropriate address using
information in local tables.

    john