> On Oct 11, 2016, at 8:31 PM, Martin Thomson <[email protected]> wrote:
>
>> I believe your concept is much to narrow.
>
> I tend to agree, though that hinges on your definition of
> "cross-origin". In the web world, that has a very specific meaning.
> What you could say that "if the client doesn't care who it is talking
> to, or it has some secondary means of validating the identity of a
> server, then this isn't a concern".
No, it is not "don't care". It is rather that it is quite sufficient
to know that mail is being delivered to whichever server the next-hop
domain designates as its mailhost. If some domain wants to publish
(DNSSEC-signed) records:
example.com. MX 0 mail.ietf.org.
or
_xmpp-server._tcp.example.com. SRV 0 100 5222 jabber.ietf.org.
to the effect that its email or XMPP servers are running on some
outsourced host, it is free to do so. The target host may not
offer the service, and may turn away clients trying to send email
or instant messages to [email protected], but there is no security
impact on either the client or ietf.org beyond any extra load. And
of course extra load be imposed much more effectively by other means.
> In the mail case, I continue to be astonished that this isn't a
> material problem, but I guess that there really must be these
> secondary mechanisms.
No secondary mechanisms are present or needed. The issue is
simply moot. The attacker gains no advantage by redirecting
his own domain's SMTP, XMPP, ... traffic to an unwitting target
server.
What's odd is not that SMTP and XMPP are immune, but rather
the astonishing subtlety of the Web security model, which
makes web applications vulnerable.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
