On 12/9/15 10:59 PM, Tom Hendrikx wrote:
>> unbound-host -rvD spike.porcupine.org
>> unbound-host -rvD postfix.org
>> unbound-host -rvD mail.cloud9.net
> Most DNSxLs are ip based, not hostname based.
In fact I used the reverse IP to query the DNSBL.
> The client's ip is provided by the tcp/ip stack of our own server. No
DNSSEC needed.
A MITM attack can easily spoof those values. DNSSEC is the only way I
have to verify
the correspondence between the info I have and the info from your tcp/ip
stack, that is,
it is the only way I have to know whether I am connected to you or the
MITM. In the
case of e-mail, to get into my inbox you would need to implement SPF,
DKIM, DMARC, and DANE.
DNSSEC works for your e-mail, for your web page, and pretty much
everything else
you are serving on the internet. Are you sure that your postfix
distribution via http
is exactly the one we downloaded? A MITM can spoof your web page,
delivering a tampered
package with its tampered signature. The only way you have to shield us
both from
the MITM is to use a well configured DNSSEC, with HTTPS and TLSA.
> If you need more trust in DNSxL data retrieval, then sign up and pay
for list access, ...
Do you realise that this is breaking the e-mail infrastructure? The
problem we are
discussing here is part of the greater problem of net neutrality and our
right to speak.
My standpoint here is that you do not need to pay for your e-mail to get
into my inbox.
If you want to exchange e-mail, all you need is a "proper" e-mail
server. If we are
pushed and pulled into purchasing dogmatic DNSxL, we will soon find out
that
the same are effectively censoring e-mail, because they can black-list
your IP. They
can also white-list spammers. No, DNSxL is not the solution. DNSxL is
part of the problem.
I prefer direct, point-to-point, DNSSEC authentication with DANE. I do
not want to throw away
the baby with the bathwater, however. If I instruct my DNSSEC resolver
to reject all those
"insecure" IPs, and I instruct postfix to reject all non-DANE clients,
then you automatically
disappear from the internet. So far, I have managed to keep the baby,
rejecting only 1% of it.
The remaining 3% of bathwater does not go away with DNSxL, as you can see.
As small as it looks,3% bath water is evidence of a security problem: a
single e-mail
from that pool is good enoughto cause damages while hiding its identity
from the forensics.
We must find a way to reject telnet-like cloud-based e-mails.
SB
