Subject: [Asrg] DNS-based Email Sender Authentication Mechanisms: a Critical Review

From: Amir Herzberg <[email-masked]>
Date: Sun, 24 May 2009 10:58:49 +0300

Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID Framework
(SIDF); it's in process of publication at `computer & security`, you can see
it at http://dx.doi.org/10.1016/j.cose.2009.05.002 (pending editing, final
changes etc.). Nothing much new, just an attempt to provide a
fair-yet-critical survey, hopefully to help clarify this important subject.
Comments will be most welcome. Abstract below.

Amir Herzberg

Title: DNS-based Email Sender Authentication Mechanisms: a Critical Review

Abstract

We describe and compare three predominant email sender authentication
mechanisms based on DNS: SPF, DKIM and Sender-ID Framework (SIDF). These
mechanisms are designed mainly to assist in filtering of undesirable email
messages, in particular spam and phishing emails.We clarify the limitations
of these mechanisms, identify risks, and make recommendations. In
particular, we discuss potential abuse of these mechanisms to facilitate DNS
poisoning, and suggest countermeasures.

-- 
Amir Herzberg
Associate Professor, Dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 24 May 2009 09:09:48 -0700

US$ 31???

Intelligent articles in this arena are rare.  Too bad this one is effectively 
inaccessible.

d/

Amir Herzberg wrote:
> Hi guys, I wrote a `critical review' of SPF, DKIM and Sender-ID 
> Framework (SIDF); it's in process of publication at `computer & 
> security`, you can see it at 
> http://dx.doi.org/10.1016/j.cose.2009.05.002 (pending editing, final 
> fair-yet-critical survey, hopefully to help clarify this important 
> subject. Comments will be most welcome. Abstract below.
> 
> Amir Herzberg
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Steve Atkins <[email-masked]>
Date: Sun, 24 May 2009 09:12:26 -0700

On May 24, 2009, at 12:58 AM, Amir Herzberg wrote:

> security`, you can see it at http://dx.doi.org/10.1016/j.cose.2009.05.002 
>  (pending editing, final changes etc.). Nothing much new, just an  
> attempt to provide a fair-yet-critical survey, hopefully to help  
> clarify this important subject. Comments will be most welcome.  
> Abstract below.

I'm not going to pay $31.50 to review someone's work. Nor is anyone  
else, I suspect.

Cheers,
   Steve

> We describe and compare three predominant email sender  
> authentication mechanisms based on DNS: SPF, DKIM and Sender-ID  
> Framework (SIDF). These mechanisms are designed mainly to assist in  
> filtering of undesirable email messages, in particular spam and  
> phishing emails.We clarify the limitations of these mechanisms,  
> identify risks, and make recommendations. In particular, we discuss  
> potential abuse of these mechanisms to facilitate DNS poisoning, and  
> suggest countermeasures.
>
> -- 
> Amir Herzberg
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

---

From: Sean Shen <[email-masked]>
Date: Mon, 25 May 2009 14:26:32 +0800

> > http://dx.doi.org/10.1016/j.cose.2009.05.002
> I'm not going to pay $31.50 to review someone's work. Nor is 
> anyone else, I suspect.
> 
> Cheers,
>    Steve

I got very surprised that on asrg mailinglist I was induced to pay and
review a paper. Is this a mistake or an advertisement?

Sean

---

From: grenville armitage <[email-masked]>
Date: Mon, 25 May 2009 17:16:10 +1000

Sean Shen wrote:
	[..]
> on asrg mailinglist I was induced to pay and

Chill, people. The original email didn't solicit reviews,
just comments (seems to me the author just wants to stimulate
discussion). The original author wont be getting any of the money.
As is common in academic research, papers get published in
journals who often charge money for online access to papers.
This paper is essentially free to staff and students of companies
(often universities and some R&D labs) with institutional licenses 
for online papers. Wouldn't surprise me if the original poster didn't
even realise the journal was charging for access. Yes, other people
miss out - which is unfortunate, but hardly a conspiracy to undermine 
the ASRG.

cheers,
gja

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Mon, 25 May 2009 12:17:08 +0200

Amir should send it to the list before sending it to be published by Science Direct. I'm 
not sure, but it seems to me that even he, he can't distribute a copy of the paper, now. 
Unfortunately.

I have a copy of it (but I haven't yet read it), as our library subscribes to that 
service, but, as long as I know, I can't either redistribute it.

Cheers,

Steve Atkins wrote:
>> mechanisms based on DNS: SPF, DKIM and Sender-ID Framework (SIDF). 
>> These mechanisms are designed mainly to assist in filtering of 
>> undesirable email messages, in particular spam and phishing emails.We 
>> clarify the limitations of these mechanisms, identify risks, and make 
>> recommendations. In particular, we discuss potential abuse of these 
>> mechanisms to facilitate DNS poisoning, and suggest countermeasures.
>>
>> -- 
>> Amir Herzberg

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]

---

From: Amir Herzberg <[email-masked]>
Date: Mon, 25 May 2009 17:18:56 +0300

gja, thanks, you got the situation correctly. In fact, from our campus,
access to this publication is free in transparent manner, so I quite forgot
that it is not free to all... sorry! Tks to others who have explained the
situation on the list or to me (off-list).

Anyway, Elsevier's copyright conditions are very reasonable and in
particular they do allow me (i.e., authors) to post pre-published versions
in personal site, so I've put it on my googlepages at:
http://amir.herzberg.googlepages.com/somerecentpapers.

I hope this is now acceptable and people don't suspect me of `spamming' just
for sending a link to a related review paper (some people complained I'm
`spamming' but I hope they just thought I'm trying to actually convince you
to pay for the paper... at least, I hope that's what they meant).

Have great day, Amir Herzberg

On Mon, May 25, 2009 at 10:16 AM, grenville armitage
<[email-masked]>wrote:

> (often universities and some R&D labs) with institutional licenses for
> online papers. Wouldn't surprise me if the original poster didn't
> miss out - which is unfortunate, but hardly a conspiracy to undermine the
> ASRG.
>
> cheers,
> gja
>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 May 2009 08:54:09 -0700

http://amir.herzberg.googlepages.com/somerecentpapers

This paper refers to DNS poisoning without fully exploring how SPF  
might be used to enable DNS poisoning.  SPF might be checked by MUAs  
in some cases.   More than just resolvers associated with MTAs are  
affected, so separate resolvers for MTAs, which themselves might  
become poisoned, does not represent a good solution.  SPF provides bad  
actors access to DNS resolvers that might otherwise be protected by  
ACLs.  At today's Internet speeds, DNS transactional IDs do not  
represent adequate protection.  SPF's use of macros ignores this  
security venerability.  Suggesting the use of DNSSEC is not reasonable  
justification for ignoring this problem.

SPF supports the use of macros to access A, AAAA, PTR and TXT DNS  
resource records.  These macros might expand local-parts within the  
email-message, which means SPF records may NOT be fully cacheable.   
Subsequent record resolutions can be triggered by the SPF macros,  
where as may as one hundred such record resolutions can occur when  
resolving a single SMTP source authorization.

These subsequent resolution events can be directed toward both a DNS  
resolver under the control of the bad actor to obtain timing and  
target information for the remaining tens or hundreds of record  
resolutions made against their victim's caching resolvers.  This  
attack can be renewed by simply changing local-parts within either the  
bounce address or the PRA.  Perhaps both the bounce address and the  
PRA authorization verifications are attempted, which would have the  
effect of doubling the amount of traffic.

SPF enables both sustained DDoS attacks and is able to bypass  
protections otherwise afforded by ACLs on local resolvers.  It seems  
that risk should be mentioned in a critical review.

-Doug

---

From: der Mouse <[email-masked]>
Date: Mon, 25 May 2009 11:59:08 -0400 (EDT)

> Suggesting the use of DNSSEC is not reasonable justification for
> ignoring this problem.

Why not?

I see nothing wrong with the stance of "if you stubbornly refuse to
deploy known solutions to the problem, you will have to live with
continued exposure to the problem".  For example, nobody sheds a tear
over the insecurities in rsh, because we have ssh; why do you feel the
analogy to unsecured DNS and DNSSEC is invalid?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: John Leslie <[email-masked]>
Date: Mon, 25 May 2009 13:12:13 -0400

Douglas Otis <[email-masked]> wrote:
> might be used to enable DNS poisoning.

   Doug perhaps asks too much... But the paper does explain a particular
exploit, where SPF records are used to cause particular DNS queries at
"known" times, to which forged responses can be spoofed, potentially
greatly increasing the risk of DNS poisoning.

   Discussion of that particular exploit does seem in scope.

   The paper is somewhat disappointing in only mentioning "rate limiting"
and "dedicated DNS proxy" as countermeasures, without any particulars.

   Is there any interest in fleshing out these countermeasures?

> resolving a single SMTP source authorization.

   This sounds like the sort of issue where a "dedicated DNS proxy"
for SPF queries could apply rate-limiting to good advantage. Of
course, it would end up deliviering "less" than SPF proponents have
been claiming as SPF's "advantages;" but I suspect Doug is not alone
in considering such a "feature" as beneficial.

   ;^)

--
John Leslie <[email-masked]>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 May 2009 11:49:40 -0700

On May 25, 2009, at 8:59 AM, der Mouse wrote:

> continued exposure to the problem".  For example, nobody sheds a  
> tear over the insecurities in rsh, because we have ssh; why do you  
> feel the analogy to unsecured DNS and DNSSEC is invalid?

Selecting which shell access method to use does not depend upon prior  
adoption by the rest of the Internet.  A requisite massive adoption of  
DNSSEC before a reasonable level of protection is obtained is where  
this analogy fails.

The major proponent of Sender-ID still does not offer DNSSEC, and has  
only recently announced DNSSEC in their future OS versions.  Even when  
DNSSEC becomes available, validating resolvers will need to be  
configured with “trust anchors” for zones where validation is  
possible.  DNSSEC had expected resolvers would be configured with a  
trust anchor at the root zone, however, the root zone is not signed at  
this time, nor are most of the TLDs.

Until that time, multiple trust anchors are required for DNSSEC, where  
servers will need to be configured to accept some unsigned  
information.  Secondly, use of DNSSEC also requires EDNS0, which  
actually makes the SPF macro feature, in conjunction with with the  
inordinate number of transactions created by recipients processing  
SPF, even more dangerous from an DDoS perspective.

The safest method for deploying DNSSEC could be by using SCTP as a  
preferred transport for DNS.  Even this type of conclusion is likely  
another decade away.  Until then, not being abusive and remaining  
cautious about DNS use remains the best current advice.

-Doug

---

From: Amir Herzberg <[email-masked]>
Date: Mon, 25 May 2009 23:45:42 +0300

On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <[email-masked]> wrote:

> This paper refers to DNS poisoning without fully exploring how SPF might be
> used to enable DNS poisoning.  SPF might be checked by MUAs in some cases.
> More than just resolvers associated with MTAs are affected, so separate
> resolvers for MTAs, which themselves might become poisoned, does not
> represent a good solution.

Sorry - I simply was not aware of SPF checks being invoked by MUAs. I
actually find it a bit strange that MUAs would do SPF validations,
considering they don't get MAIL FROM, but human ingenuity is endless and I
apologize for this ignorance. Doug, can you give me specific examples -
preferably of common MUA clients and if possible, of appropriate
documentation so I can read about it and/or test it? Tks!

>  SPF provides bad actors access to DNS resolvers that might otherwise be
> protected by ACLs.  At today's Internet speeds, DNS transactional IDs do not
> represent adequate protection.  SPF's use of macros ignores this security
> venerability.  Suggesting the use of DNSSEC is not reasonable justification
> for ignoring this problem.

I believe my text  already makes this argument except for considering the
issue limited to MTAs, MDAs.

>
> SPF supports the use of macros to access A, AAAA, PTR and TXT DNS resource
> records.  These macros might expand local-parts within the email-message,
> which means SPF records may NOT be fully cacheable.  Subsequent record
> resolutions can be triggered by the SPF macros, where as may as one hundred
> such record resolutions can occur when resolving a single SMTP source
> authorization.

But spec says (and even if it didn't, common sense would) that a reasonable
limit of resolutions, say 10, should be used. I think I even discussed this,
I definitely considered discussing this.

> resolver under the control of the bad actor to obtain timing and target
> information for the remaining tens or hundreds of record resolutions made
> against their victim's caching resolvers.  This attack can be renewed by
> simply changing local-parts within either the bounce address or the PRA.
>  Perhaps both the bounce address and the PRA authorization verifications are
> attempted, which would have the effect of doubling the amount of traffic.

This is indeed the attack I've sketched in the paper; do u think more
details were needed? Maybe I can simply add citation of some detailed
publication on this since I think adding much more details is not reasonable
for such a review.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 May 2009 18:23:37 -0700

On May 25, 2009, at 1:45 PM, Amir Herzberg wrote:

>> might be used to enable DNS poisoning.  SPF might be checked by  
>> MUAs in some cases.   More than just resolvers associated with MTAs  
>> are affected, so separate resolvers for MTAs, which themselves  
>> might become poisoned, does not represent a good solution.
>
> Sorry - I simply was not aware of SPF checks being invoked by MUAs.  
> I actually find it a bit strange that MUAs would do SPF validations,  
> considering they don't get MAIL FROM, but human ingenuity is endless  
> and I apologize for this ignorance. Doug, can you give me specific  
> examples - preferably of common MUA clients and if possible, of  
> appropriate documentation so I can read about it and/or test it? Tks!

SPF can be found in ClamAV, SpamAssassin, etc. extend filtering of  
incoming email at the desktop for any type of MUA.  There are even  
Thunderbird plugins that specifically provide SPF resolution.

>> SPF provides bad actors access to DNS resolvers that might  
>> otherwise be protected by ACLs.  At today's Internet speeds, DNS  
>> transactional IDs do not represent adequate protection.  SPF's use  
>> of macros ignores this security venerability.  Suggesting the use  
>> of DNSSEC is not reasonable justification for ignoring this problem.
>
> I believe my text  already makes this argument except for  
> considering the issue limited to MTAs, MDAs.

A common mistake.

> But spec says (and even if it didn't, common sense would) that a  
> reasonable limit of resolutions, say 10, should be used. I think I  
> even discussed this, I definitely considered discussing this.

When the goal is to poison DNS, the SPF specifications limit  
resolution to 10 mechanisms, and then the resolution of MX records  
(one such mechanism) to 10. 10 x 10 = 100.  The draft that I wrote  
long ago demonstrated 100 transactions using unmodified off-the-shelf  
SPF libraries.

>> These subsequent resolution events can be directed toward both a  
>> DNS resolver under the control of the bad actor to obtain timing  
>> and target information for the remaining tens or hundreds of record  
>> attack can be renewed by simply changing local-parts within either  
>> the bounce address or the PRA.  Perhaps both the bounce address and  
>> the PRA authorization verifications are attempted, which would have  
>> the effect of doubling the amount of traffic.
>
> This is indeed the attack I've sketched in the paper; do u think  
> more details were needed? Maybe I can simply add citation of some  
> detailed publication on this since I think adding much more details  
> is not reasonable for such a review.

You might want to go through the numbers.  When SPF records are being  
cached, but then expanded upon using macros, the cost to the attacker  
becomes nil, however the impact on their victim can profound.

-Doug

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Mon, 25 May 2009 23:22:20 +0200

Amir Herzberg wrote:
> On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     become poisoned, does not represent a good solution. 
> 
> 
> considering they don't get MAIL FROM, but human ingenuity is endless and 
> I apologize for this ignorance. Doug, can you give me specific examples 
> - preferably of common MUA clients and if possible, of appropriate 

Well. Me too, I don't understand why it could be interesting to check SPF in the MUA. It 
may be interesting to check SPF when one have access to both sender domain and IP address 
of the SMTP client connecting to the MTA. This information isn't usually available to the 
MUA, unless it will trust on data available on headers.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 26 May 2009 18:17:29 -0400

> MUA, unless it will trust on data available on headers.

The Thunderbird SPF/DK plugin, for example, has a configuration option 
that tells it how to parse the Received lines to pluck out the IP and 
HELO recorded in the Received line the user's perimeter MTA has generated.

It works well enough in that regard.

[The plugin isn't compliant with SPF per-se, it checks From:, because it 
usually can't get the MAIL FROM.  This is configurable.]

I experimented with it.  It works.  But doesn't add enough to be worth 
while if you already have decent MTA-end filtering.

If you don't have decent MTA filtering, it might be worthwhile.

---

From: Amir Herzberg <[email-masked]>
Date: Wed, 27 May 2009 08:59:05 +0300

Doug, thanks! I completely agree that applying SPF at the client - or in
fact, anywhere after the border MTA - is probably a very poor idea, due to
the potential exposure to DoS and DNS poisoning exploits. I just didn't
think this people would do it - I'll try to add warning against it. This is
far beyond the question of whether there is also some real goal in doing SPF
validation at this point (client) [referring to Chris's note].

And I agree that it may be worthwhile also mentioning the 10*10
amplification factor for implementations that allow 10 mechanisms where each
could do 10 MX (or PTR) RR lookups, for a total of 100 DNS queries (or I
think actually 111). Notice that again, the use of SPF by multiple mail
agents, e.g. at the client, would provide even further amplification.

Amir

On Tue, May 26, 2009 at 4:23 AM, Douglas Otis <[email-masked]> wrote:

>>> This paper refers to DNS poisoning without fully exploring how SPF might
>>> be used to enable DNS poisoning.  SPF might be checked by MUAs in some
>>> cases.   More than just resolvers associated with MTAs are affected, so
>>> separate resolvers for MTAs, which themselves might become poisoned, does
>>> not represent a good solution.
>>>
>>
> SPF can be found in ClamAV, SpamAssassin, etc. extend filtering of incoming
> email at the desktop for any type of MUA.  There are even Thunderbird
> plugins that specifically provide SPF resolution.
>
>> reasonable limit of resolutions, say 10, should be used. I think I even
>> discussed this, I definitely considered discussing this.
>>
>
> When the goal is to poison DNS, the SPF specifications limit resolution to
> 10 mechanisms, and then the resolution of MX records (one such mechanism) to
> 10. 10 x 10 = 100.  The draft that I wrote long ago demonstrated 100
> transactions using unmodified off-the-shelf SPF libraries.
>

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 27 May 2009 12:22:13 +0200

> If you don't have decent MTA filtering, it might be worthwhile.

OK, but... Well, you said "if you don't have decent MTA filtering".

Looks like "hack", "workaround", ...

IMHO, one of the problems in spam filtering is that we're allways including and accepting 
the existence of bad solutions, bad administered mail servers, bad practices, ...

It seems to me that ASRG should, first of all, encourage best practices.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 May 2009 18:05:29 +0200

Douglas Otis wrote:
> preferred transport for DNS.

Just using TCP would prevent most of the DNS poisoning attacks that 
Amir's paper reports.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 May 2009 09:36:09 -0700

Amir Herzberg wrote:
>     Nothing much new, just an attempt to provide a

Perhaps I misunderstand the paper, but it appears to be asserting that DKIM 
validates the From: field.

>      DKIM allows authentication of multiple
> email header ﬁelds, including the sender identity displayed to the recipient; in
> that regard, it is similar to SIDF

Since DKIM does nothing of the kind, that seems a rather fundamental point of 
departure for evaluating the paper.

DKIM authenticates the signing domain, and it ensures data integrity for the 
covered header fields and body, from the place of signing to the place of 
verification.  But it does not authenticate any of the message contents, such as 
the sender identity.

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 May 2009 10:02:17 -0700

On May 26, 2009, at 10:59 PM, Amir Herzberg wrote:

> Doug, thanks! I completely agree that applying SPF at the client -  
> or in fact, anywhere after the border MTA - is probably a very poor  
> idea, due to the potential exposure to DoS and DNS poisoning  
> exploits. I just didn't think this people would do it - I'll try to  
> add warning against it. This is far beyond the question of whether  
> there is also some real goal in doing SPF validation at this point  
> (client) [referring to Chris's note].

A warning is likely not something a typical user would know how to  
control.  SPF record processing is found lurking in many places.   
Within AV and various email filtering and annotation schemes that do  
not indicate the processing of SPF records will occur.    
Unfortunately, some of these schemes are rather poorly written and  
even lack some of the recommended albeit generous processing limits.

> amplification factor for implementations that allow 10 mechanisms  
> where each could do 10 MX (or PTR) RR lookups, for a total of 100  
> DNS queries (or I think actually 111). Notice that again, the use of  
> SPF by multiple mail agents, e.g. at the client, would provide even  
> further amplification.

The important aspect of this concern is that SPF _macros_ allow the  
SPF record itself to be cached and thereby not expend _any_ additional  
resources of the attacker.  Macro expansion of cached SPF records by  
recipients can generate 10x transactions as a completely free gift to  
the attacker!   This free attack eliminates a major factor that  
discourage most DDoS attacks.  This represents an indirect attack that  
is difficult to trace,  that is likely not logged, and is  
substantially free because a final transaction, or even the end of the  
SPF record, can result in full authorization regardless of the MTA IP  
address.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 27 May 2009 13:19:06 -0400

> OK, but... Well, you said "if you don't have decent MTA filtering".

I did.

> Looks like "hack", "workaround", ...

Yup.  No way I'd deploy it to our users.

> the existence of bad solutions, bad administered mail servers, bad practices, ...

I wouldn't "include or accept" it, or at most perhaps note that it's 
somewhat usable in idiosyncratic situations.  FSVO "somewhat" and "usable".

> It seems to me that ASRG should, first of all, encourage best practices.

Well yeah, but, you even have a hard time pushing MTA-end filtering as BCP.

Politics.  Sigh.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 May 2009 19:46:50 +0200

> http://amir.herzberg.googlepages.com/somerecentpapers.

I've marked a number of snippets where reading faltered. Most of them 
are typos or language doubts (my English barely supports me) while 
some may stir some discussion... I just paste that stuff below, hoping 
some of it may help you better your paper.

format: "---" snippet empty-line "(" comment ")"

---
extremely low-cost, especially when sending ‘bulk’ mail

(formally incorrect, the cost doesn't usually decrease with scale)
---
Spam: there are different definitions of spam; we use the term spam to 
refer to email sent to many recipients (‘bulk’), who have not 
expressed desire to receive it.

(This also includes "legal" advertising, with variations on the extent 
to which providing one's email address expresses the desire to receive 
advertisements. Zombie-based spam is a different beast)
---
These mechanisms use the DNS system (in different ways), to securely 
identify the sender

(drop /securely/...)
---
SIDF: The Sender-ID Framework (SDIF)

(typo)
---
In particular, we make the following observations and recommendations

(Perhaps s/particular/conclusion/? All observation are unjustified at 
this point. It is not obvious for a reader whether this is an 
executive's summary and the recommendations will be derived later. 
BTW, I'd suggest to relegate part of the introductory material to some 
appendixes, so as to get to the core without interruptions)
---
There is also a side-benefit: eliminating unnecessary filtering, esp. 
the computationally intensive and imprecise content-based filtering.

(This stance disagrees with the recommendation "Do not filter emails 
based solely on SPF, DKIM and/or SIDF failures" a few lines below. The 
side-benefit is probably limited to _help_ eliminating content-based 
filtering...)
---
it is recommended that senders would mark their use of SPF in the 
email envelope,

(How? Possibly using VHLO or other non-standard protocol extension?)
---
e.g. www.foo.org.

(www.example.com is more canonical)
---
an the top is a set of root DNS

(typo, an=and)
---
Reverse DNS (rDNS) record [...] However, notice that small 
organizations [...] ownership of the corresponding rDNS entries.

(s/However, notice that/Depending on the "reseller",/: When choosing 
an ISP for connecting a mail server, would you recommend to consider 
how do they arrange for rDNS and whois? Also, s/ownership/delegation/. 
Isn't it worth to mention "PTR"?)
---
Blacklist DNS records

(should note that DNSBL are not authoritative/hierarchical)
---
DNS Security. The DNS provides an open directory service[...]

("DNS vulnerabilities" may be a more appropriate subtitle)
---
Bob’s MUA, MUABob, picks up email from the MDA.

(formally incorrect, it picks it up from the mailbox where the MDA 
delivered it.)
---
When the MUA is an application running on the same machine as the MDA, 
mail pickup is done via the file system.

(not necessarily; in addition, MDAs may run LMTP or any other network 
transport)
---
either using either an appropriate web-mail form, or using a mail 
pickup protocol, typically either

(too many "either", rewording is advisable)
---
S/MIME [27] and OpenPGP [12], use public key encryption and signatures 
to provide end-to-end protection of the confidentiality and 
authenticity of email

(Not necessarily end-to-end: I've heard of ESPs who crypt messages at 
the MDA stage, in order to grant confidentiality to their IMAP mailbox 
storage. It may be mentioned that eavesdropper who work at the ESP's 
are difficult to guard against, if the question or trusting one's ESP 
is raised.)
---
but can do use a fake domain

(is "can do" syntactically correct?)
---
claiming to be an outgoing MTA of a.com

(formally incorrect, SMTP doesn't allow a sender to say whose domain 
it belongs to --again, unless using VHLO)
---
cannot do not have

(is that syntactically correct?)
---
cannot intercept the ISN sent by the other party, therefore it can 
only guess the

(RFC1948 is of 1996, Vulnerability Note VU#498440 is of 2002, so TCP 
should now be safe. However, RFC 3552 of 2003 still considers blind 
attacks... Is it because old hardware may still be vulnerable?)
---
not all companies and ISPs enforce port 25 blocking.

(This is a good occasion to recommend port 587)
---
SPF validation is performed using the email address specified by the 
sending MTA in the HELO directive, identifying the domain that the 
sending MTA belongs to.

("email address" is formally incorrect, EHLO specifies a host name)
---
which IP addresses it intents to use

(typo)
---
spf1.0 +IP4 : 1:2:3:4 all

(typos)
---
The receiving mail agent (MUA or MTA) evaluates the terms

(Here you assume that MUAs can learn IP addresses parsing the Received 
headers and then carry out SPF checks --see discussion with Doug)
---
aa.bb.cc= 1.2.3.4

(typo)
---
Fig. 2

(The policy says ~all, different than the text)
---
if Bob is an MTA and transfers the email

(if Bob's MTA accepts the email message)
---
‘fake bounces’ are sometimes referred to as ‘Joe-job attack’

("backscatter" is also a frequently used term)
---
However, this implies that the recipient will consider this email as 
originating from foo.org.

(formally incorrect, most recipients consider the "From" header instead)
---
This will allow the recipient to avoid ‘false positives’ (incorrectly 
blocking valid mail for spam/phishing)

(SPF checking is typically done at the MAIL FROM stage, much before 
Authentication-results has a chance of being evaluated)
---
the receivers still have to make two DNS queries.

(didactic style requires to explain they are one for TXT and one for SPF)
---
we can place the policy record in an arbitrary DNS record controlled 
by the sender

(this proposal to change the SPF specs should be identified as such; 
BTW, rewriting rfc4408 is somewhat overdue)
---
retrieving the policy record policy from DNS.

(typo)
---
One clear conclusion here is that the receiving MTA should use a 
dedicated DNS proxy

(Well, this is a good advice also for performance reasons. However, it 
is not clear if you intend to suggest using multiple DNS proxies, e.g. 
a different one for outgoing mail, host maintenance and auto upgrades, 
nearby clients, etcetera.)
---
Based on experimental works on phishing [10, 16], we low detection rates

(who is "we"?)
---
SIDF records specify the relevant identifier (or identifiers) by the 
MFROM and PRA keywords

(Those keywords define the so-called "scope" of SIDF checking. Using 
such term may result in better wording of the following text, where it 
is explained that incompatibility stems from defining an incompatible 
default scope)
---
In addition, both proposals required complex key-management

(key-management is never simple. Certainly, it is not because of that 
complexity that so few clients can handle PGP. The fact is that 
classical encryption has been retrofitted, while DKIM is email-born. 
They can be viewed as complementary, though)
---
these standards do not define how a sender can specify that all of its 
email is signed

(Instead of "specify", terms such as "announce" or "publish" are not 
misunderstood as operative configuration rules)
---
(d) support for signing email headers

(what about "support for signing a signer-chosen selection of email 
headers"?)
---
19. Kucherawy, M.: Message Header Field for Indicating Message 
Authentication Status. Internet draft 
draft-kucherawy-sender-auth-header-15 (2008)

(this is now RFC 5451, April 2009)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 May 2009 10:57:29 -0700

> Just using TCP would prevent most of the DNS poisoning attacks that  

TCP is prone to DDoS attack.  As such,TCP is seldom used with DNS.   
TCP is also the first transport dropped when resources are exhausted  
on DNS servers.  Whereas SCTP offers extremely important defenses  
against DDoS abuse and should not need abandonment.  SCTP returns a  
cookie as a place-holder for resources that are not committed until  
the cookie is returned.  This provides the benefit of being able to  
safely exchange data sooner, while also being assured source IP  
addresses are not being spoofed.  SCTP has its own 32 bit  
transactional ID that further extends 16 bit transactional ID within  
the DNS message.   SCTP can also sustain virtual connections while  
consuming little system overhead.   Such connections can offer lower  
latency than UDP.  SCTP would also eliminate the need for EDSNS0.

A single SCTP connection can support thousands of simultaneous  
streams, where queries and responses are not exposed to head of queue  
blocking or complex buffering, which is often a problem when using  
TCP.  SCTP also provides a means to support multi-homing, where one  
address can identify alternative paths  When one path fails to  
respond, an alternative is immediately employed.  Such fail-over  
method is likely many times faster than exponential back-off used  
during DNS UDP recovery and the locating of a different authoritative  
DNS server.

SCTP provides about the same error detection rate for Jumbo frames as  
does the IEEE CRC for 1.5 KB frames.  The SCTP error detection  
algorithm is now supported in several NICs and now has dedicated  
instructions within the i7 core processors.  There is also OS support  
for UDP tunneling of SCTP when supporting legacy NATs and firewalls.   
Until there is an significant incentive to make DNS more robust, use  
of SCTP is likely to remain just a good and under appreciated option.

-Doug

---

From: der Mouse <[email-masked]>
Date: Wed, 27 May 2009 13:59:45 -0400 (EDT)

> I've marked a number of snippets [...]

I'm basing my comments here on Alessandro's responses; I don't have the
time and patience at the moment to grind through converting a PDF
(which is what this appears to be discussing) into something readable.

> (formally incorrect, the cost doesn't usually decrease with scale)

Hm?  You think it costs a thousand times as much to run a mail system
sending 50,000,000 messages a month as it does to run a mail system
sending 50,000 messages a month?

I find that..questionable.

> there are different definitions of spam; we use the term spam to
> refer to [UBE]

> (This also includes "legal" advertising, [...])

Certainly.  So?

> When choosing an ISP for connecting a mail server, would you
> recommend to consider how do they arrange for rDNS and whois?

Certainly, if they care about rDNS and whois.  (I would hope anyone
interested in following best practices would care about each.  I've
seen things like "nobody cares about rDNS these days" said; in my
admittedly limited experience, clue level correlates remarkably well
with not sharing such points of view.)

> (should note that DNSBL are not authoritative/hierarchical)

In what sense are DNSBLs not authoritative?

> it belongs to --again, unless using VHLO)

I think this is wrong, actually; even as far back as HELO, never mind
EHLO, the sender is required to identify itself, thereby indicating a
domain it belongs to.  (That next to nobody pays attention to HELO/EHLO
arguments is a separate issue.)  To what extent "I belong to
example.com" from an SMTP client is equivalent to "I'm an outgoing MTA
of example.com" is debatable, especially in cases where the EHLO
argument is something like pool18-host422.provider.net....

> ("backscatter" is also a frequently used term)

It's not clear from the context available to me whether "fake bounces"
in the original refers to mail forged to look like bounces, or bounces
of forged mail.  Neither one is what I understand a joe-job to be: my
understanding of a joe-job is the attacker forging the victim's domain
into from fields, either envelope or header.  The bounces resulting
from sending joe-job mail to nonworking addresses are the second kind
of "fake bounces", but a joe-job is not the same thing as the fallout
from a joe-job.  (My understanding of "backscatter" is that it refers
to the second kind of "fake bounces".  I've also heard/seen it called
"blowback", though I'm not sure how reasonable that is compared to
other uses of the word.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 May 2009 12:02:22 -0700

> with not sharing such points of view.)

There are different geographic regions and organizations that refuse  
to publish reverse DNS.  Reverse DNS is normally controlled by the  
holder of the IP address, where the forward DNS is normally controlled  
by the entity offering a service. When a PTR record in the reverse DNS  
appears to match with the service offered, the domain using the IP  
address is known by the IP address holder.  However, it does not mean  
the entity offering the service is controlled by that domain.  SSL  
certs attempt to convey that information in a much safer fashion.  In  
addition, it is often the case where the number of PTR records that  
can be published represent only a small faction of the domains  
legitimately using the IP address.   In the case of email, reverse DNS  
entries are often used to divine some deeper, often undefined, meaning  
based upon the content of a PTR records found at the in-addr.arpa  
zone.  As an anti-abuse effort,  some providers in North America do  
not accept connections without a reverse DNS entry being found.  As a  
result, these providers may be unable to communicate with some  
organizations or geographic regions.  Who is wrong, because in the  
case of email, reverse DNS is clearly being misused.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 27 May 2009 15:16:53 -0400

> "blowback", though I'm not sure how reasonable that is compared to

Within context, "fake bounces" is more correctly referring to 
backscatter.  "joe-job" is a different concept altogether, and more 
refers to a specific _intent_ of the forgery.  Not all job-jobs can 
cause backscatter.

As such, "are sometimes referred to as ‘Joe-job attack’" is incorrect.

A "Joe-job" is intended to cause (often purely reputational) harm to the 
joe-jobbee (the forged person).  The message _itself_ may yield no 
direct benefit to the "job-jobber" (the person doing the forgery).

It may not be the From address.  It could be links or the text of the 
email.  Etc.

For example, let's say you got a gmail address, and sent out, without 
faking any addresses, the following email:

--------------------------------------------------
Hi, I'm Chris Lewis, I'm a member of NAMBLA, and am looking for child 
porn.  You can reach me at <my real address>
---------------------------------------------------

This a joe job.  But can't "fake bounce"/backscatter.  Any bounces are 
"real".

Forging the MAIL FROM line to have my real address means that it can 
"fake bounce"/backscatter.  It's still a joe-job too.

Not all "fake bounces"/"backscatter" are joe-jobs and vice-versa.

As a natural consequence of phishing (attempting to fool the recipient 
into giving their credentials away, and the forger derives direct 
benefit from the email), the MAIL FROM address will often be of the 
phished bank.  But it doesn't need to be, and very often isn't.  Of 
course SPF only helps when it _is_ the phished bank in the MAIL FROM 
address (or the phisher is stupid enough to forge some _other_ domain 
that has conflicting SPF).

---

From: der Mouse <[email-masked]>
Date: Wed, 27 May 2009 15:24:13 -0400 (EDT)

> to publish reverse DNS.

This is true.  In my experience being one of them correlates
positively, and at least moderately strongly (though of course not
perfectly), with being part of the precipitate.

Certainly there are clued people, and even small-to-medium
organizations, which are for various reasons behind rDNS-free
connectivity.  IME they are apologetic about it rather than exhibiting
the sort of "what do you care about _that_ for, this isn't the '80s,
get with it!" attitude that seems (again, IME) to characterize the
problematic admins.

> As an anti-abuse effort, some providers in North America do not
> accept connections without a reverse DNS entry being found.

I suspect it's hardly as restricted to North America as you make it
sound.

> As a result, these providers may be unable to communicate with some
> organizations or geographic regions.

Right.  So?  Someone who doesn't tolerate dashes in domain names won't
be able to communicate with rodents-montreal.org, either.

> Who is wrong, because in the case of email, reverse DNS is clearly
> being misused.

It's not clear to me that anyone is wrong there, nor that rDNS is being
misused.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Levine <[email-masked]>
Date: 27 May 2009 21:55:10 -0000

>Title: DNS-based Email Sender Authentication Mechanisms: a Critical Review

Dave is right -- this misunderstands what DKIM does.  The only validated
identity is the signer, which need bear no relationship to any other header
domain, e.g.

 DKIM-Signature: ... d=rbn.ru; ...
 From: Bank of America Security <[email-masked]>

The From: header is signed, but the only domain that DKIM
authenticates here is rbn.ru.  It doesn't say anything about the
legitimacy or lack thereof of the address [email-masked], or of
the string "Bank of America Security" which is what a whole lot of
MUAs will actually display.

Even if the d= domain matches the domain on the From: line, it still
doesn't promise that the address is "real".  This is an important
point that a lot of people misunderstand.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 15:04:19 +0200

Douglas Otis wrote:
> TCP is prone to DDoS attack.  As such, TCP is seldom used with DNS.

I thought TCP was the default when the UDP message size is not enough. 
That's, AFAIK, the only advantage of TCP over SCTP: it's already in 
place and ready. (Yes, one needs to run firewalls and all that stuff.)

> A single SCTP connection can support thousands of simultaneous streams,

I agree SCTP is better, and it's been around for nearly a decade now. 
Yet, for those who miss it, good old TCP allows, say, a client to hold 
a couple of connections to its favorite resolver in order to avoid 
many of the threats illustrated by Kaminsky...

> There is also OS support for UDP 
> tunneling of SCTP when supporting legacy NATs and firewalls.  Until 
> there is an significant incentive to make DNS more robust, use of SCTP 
> is likely to remain just a good and under appreciated option.

It seems that DNS over SCTP would solve 90% of the problems with 10% 
of the efforts and resources required to implement DNSSEC. However, I 
hear more often about the latter than the former. How come?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 16:18:06 +0200

> perfectly), with being part of the precipitate.

(as opposed to being part of the "solution", I guess)

Possibly, this scarceness corroborates the belief that rDNS results 
are more trustworthy than direct DNS records.

>> As an anti-abuse effort, some providers [...] do not

This used to be typical of FTP servers in the '80s. However, some 
feedback loop providers apparently make use of it today. Let alone 
investigations about the PTR target being automatically generated or 
containing the "dynamic" keyword. IMHO, synthesizing informations on 
that basis is symptomatic of technologies in their infancy being 
desperately greedy for data they cannot obtain [otherwise].

> be able to communicate with rodents-montreal.org, either.

I never heard about dash-intolerants. Are you kidding?

> It's not clear to me that anyone is wrong there, nor that rDNS is being

Much like whois, rDNS is being used in relation with the possibility 
to individuate who, if any, is responsible for running a host at the 
given address. DNSBLs, certificates, reputation, etcetera, all rotate 
around allocations of those IP numbers, but rDNS dependence reveals 
unreadiness for a truly virtual environment: What if _all_ IPs were 
dynamic?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 16:16:31 +0200

Stephane Bortzmeyer wrote:
>> of the efforts and resources required to implement DNSSEC. However,
>> I hear more often about the latter than the former. How come?
> 
> I've read this message via the IETF general mailing list and so I
> missed the beginning. In what way can you compare DNSSEC (which
> provides object security) and SCTP or TCP (which provide a better
> channel security for DNS)?

The discussion was about how to get rid of the threats illustrated, 
e.g., in Kaminsky, D.: "It’s the end of the cache as we know it." In: 
Black Hat conference (2008). Online at 
http://www.doxpara.com/DMK_BO2K8.ppt

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 17:47:32 +0200

Stephane Bortzmeyer wrote:
> On Thu, May 28, 2009 at 04:16:31PM +0200,
>  Alessandro Vesely <[email-masked]> wrote 
>  a message of 14 lines which said:
> 
>> e.g., in Kaminsky, D.: "It?s the end of the cache as we know it." 
> 
> I know about Kaminsky bug, the WG "DNS operations" and "DNS
> extensions" spent a lot of time on it. Please do not restate the
> basics and explain why SCTP (or TCP) can be compared with DNSSEC
> since, as I said, DNSSEC provides *object* security and TCP (or SCTP)
> can only provide a limited *channel* security.

I don't trust the data because it is signed, I trust it because the 
signature proves that it originated from the authoritative server. 
Therefore, if I'm connected with the authoritative server over a 
trusted channel, I can trust the data even if it isn't signed. By 
induction, if a resolver only uses either signed data or trusted 
channels, I can trust it.

After all, cryptography just provides trusted channels of their own 
kind. The comparison involves the security features of those two kinds 
of channels.

The limitations in TCP or SCTP security stem from an attacker's 
ability to compromise one or more routers, so as to either tamper with 
the packets on the fly, or redirect them to some other host. That's 
much more difficult than forging the source address of an UDP packet, 
though.

---

From: SM <[email-masked]>
Date: Thu, 28 May 2009 10:11:52 -0700

At 06:04 28-05-2009, Alessandro Vesely wrote:
>Douglas Otis wrote:
>>>Just using TCP would prevent most of the DNS poisoning attacks 
>>>that Amir's paper reports.
>I thought TCP was the default when the UDP message size is not 
>enough. That's, AFAIK, the

It is.  The statement about why TCP is seldom used is incorrect.

    "UDP is not acceptable for zone transfers, but is the recommended
     method for standard queries in the Internet."

UDP is used as the message is generally less than 512 bytes.  I'm 
ignoring EDNS0 support.  If the message is truncated, a TCP connection is used.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 May 2009 17:36:30 -0700

On May 28, 2009, at 9:45 AM, David Conrad wrote:

> On May 28, 2009, at 5:47 AM, Alessandro Vesely wrote:
> Not quite.  The signature over the data proves that the holder of  
> the private key has signed the data.  The origin of that data then  
> becomes irrelevant.

This discussion started by describing how an authorization protocol  
might utilize macros embedded within a DNS cache to stage relatively  
free DDoS attacks, all of which would be made worse by DNSSEC.   
Preventing DNS poisoning was also a concern expressed, which is likely  
to go hand in hand with the DNS enabled attack.  Since DNS is normally  
connectionless, security solutions like SSL have been dismissed.    
While DNSSEC may protect against data corruption, such protection  
depends upon the thorny problem of verifying a key will be solved in a  
practical and politically acceptable manner.  This protection also  
requires authoritative servers to rapidly adopt DNSSEC without also  
confronting other insurmountable deployment issues.  Fool me once,  
shame on you.  Fool me twice...

>> trusted channel, I can trust the data even if it isn't signed.
>
> Not really.  You are relying on the fact that the authoritative  
> server and (potentially) the channels it uses to communicate to the  
> originator of the data have not been compromised.

Assume SCTP becomes generally available as a preferred transport for  
DNS.  If so, an ability to corrupt DNS information would be greatly  
reduced, whether data is signed or not.  In addition, SCTP can safely  
carry larger signed results without the DDoS concerns that will exist  
for either TCP or EDNS0 over UDP.  Deploying DNS on SCTP should be  
possible in parallel with the DNSSEC effort.

>> By induction, if a resolver only uses either signed data or trusted  
> A trusted channel is superfluous when the data is signed.

Receiving signed data represents just a fraction of the challenges  
facing DNSSEC. :^(

>> ability to compromise one or more routers, so as to either tamper  
>> with the packets on the fly, or redirect them to some other host.  
>> That's much more difficult than forging the source address of an  
>> UDP packet, though.
>
> True, but object security removes even the residual risk of channel  
> compromise (e.g., a compromised router).
>
> However, pragmatically speaking, I suspect it is going to be much,  
> much easier to get DNSSEC deployed than it would be to get every  
> router/firewall/NAT manufacturer and network operator to support/ 
> deploy SCTP, not to mention getting every DNSSEC server to support  
> DNS over SCTP.

While TCP represents a possible fall-back method whenever UDP  
overflows, TCP is not assured.  Instead of seldom, low prevalence  
might better describe TCP use in DNS.  In addition, DNS servers prefer  
UDP over TCP when resources become scarce.  TCP produces greater  
latency, requires more back and forth exchanges, and strands resources  
whenever confronting spoofed connection attempts.  While EDNS0 allows  
UDP to carry larger signed packets, this also increases UDP's exposure  
to increased reflected attacks that leverage the brute strength of DNS.

On the other hand, SCTP reserves resources until a request is  
confirmed by a returned cookie, which also allows data to be exchanged  
sooner than would be possible with TCP.  Unlike TCP, SCTP carries  
chunks over multiple streams rather than non-delineated bytes over a  
single stream.  SCTP connections consume minimal resources and can  
sustain longer sparse associations.  SCTP also tunnels over UDP to  
provide compatibility with legacy NATs and firewalls.  SCTP might soon  
become popular with browsers due to its inherent improvements on  
security and performance over TCP.  A solid SCTP stack is now  
available in FreeBSD that has corporate friendly source licenses. :^)

If there is one lesson that should have been learned from the DNSSEC  
effort, resolving DNS problems will require dedicated long term  
planning.  Within the same timeframe as DNSSEC, SCTP has been able to  
provide reliable and safe transport.  You might be using SCTP whenever  
you make a phone call or watch your TV.  It seems that the telephone,  
more than the Internet, is what people expect to just work.

-Doug

---

From: der Mouse <[email-masked]>
Date: Thu, 28 May 2009 23:47:22 -0400 (EDT)

>>> As an anti-abuse effort, some providers [...] do not accept
>>> connections without a reverse DNS entry being found.
> feedback loop providers apparently make use of it today.

As do various others - my mailserver, for example, will not accept mail
from hosts with missing or broken rDNS.

> IMHO, synthesizing informations on that basis is symptomatic of
> technologies in their infancy being desperately greedy for data they
> cannot obtain [otherwise].

"Synthesizing" information?  What's synthetic about (paraphrased) "your
rDNS is missing or broken, so I won't listen to you"?

>> Right.  So?  Someone who doesn't tolerate dashes in domain names
>> won't be able to communicate with rodents-montreal.org, either.

Not in the sense you probably mean.  The "As a result" quote appeared
to be citing this as a problem with rejecting based on missing rDNS; my
point was just that it isn't necessarily so, that just because two
sites make choices that, combined, mean they can't communicate does not
make either of those choices inherently wrong.  Dash intolerance was
just a somewhat-over-the-top example of one such choice (the paired
other choice being my choice to use a domain with a dash in it).

>> It's not clear to me that anyone is wrong there, nor that rDNS is
>> being misused.
> given address.

Sometimes.  Sometimes, as in my own case, it's not so much because it
tells me who's responsible as because it correlates with having clue
(thereby being less likely to be a problem).

> DNSBLs, certificates, reputation, etcetera, all rotate around
> allocations of those IP numbers, but rDNS dependence reveals

What if they were?  Those who care about such things would presumaaably
update their DNS as the assign and reclaim IPs.  At worst, rDNS
checking might become useless.  Neither possibility means there's
anything wrong with using it now.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 11:41:18 +0200

> rDNS is missing or broken, so I won't listen to you"?

One of the implied major premises is synthetic. The complete logic 
chain reads:

* I won't listen to clueless hosts (arbitrary, but legitimate premise)
* all hosts with a missing or broken rDNS are clueless (synthetic)
* your rDNS is missing or broken (fact)
* so I won't listen to you (conclusion)

If I lived in a land where all ISPs obey a policy of not setting rDNS, 
I could opt for setting up a host in a different country, give up 
rDNS, or emigrate. The second choice if not bad, given that I like to 
see the hardware and have a few reasons to tread this soil. Local ISP 
market should not affect the reliability of hosts operating in that area.

> [rDNS is required] because it correlates with having clue 

I'm not holding that it's wrong. Possibly, a good deal of ISPs do 
rfc2317 delegations (if the customers insist.) Hence, statistically, 
those who don't set up rDNS are clueless. However, general assumptions 
based on statistical indications are synthetic. The fact that you have 
to use them indicates that email technology (or ISP market) is immature.

Specifically, the "iprev" authentication method described in rfc5451 
should not be strictly required. At least, if an SMTP connection is 
not accepted (or accepted with high suspicion) because of that reason, 
the client should be made aware of this circumstance, possibly 
allowing it to suggest alternative authentication methods or relay its 
mail through alternative paths. (The second part of this paragraph is 
the subject of draft-vesely-vhlo.)

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 12:09:46 +0200

Paul Wouters wrote:
> On Thu, 28 May 2009, Alessandro Vesely wrote:
>> The limitations in TCP or SCTP security stem from
> 
> transport security is pretty meaningless in the DNS world which operates 
> using a distributed caching system.

One has to trust each cache! Given that it is pretty easy to predict a 
subset of the queries a given server will issue in a give time frame, 
using SCTP can improve reliability better than adding another 32bit 
random number.

> This is why dnscurve is just an 
> academic experiment that can never leave the lab for the real world.

IMHO, avoiding to base the Internet on an encumbered algorithm is 
another good reason :-/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 12:23:53 +0200

David Conrad wrote:
> However, pragmatically speaking, I suspect it is going to be much, much 
> easier to get DNSSEC deployed than it would be to get every 
> router/firewall/NAT manufacturer and network operator to support/deploy 
> SCTP, not to mention getting every DNSSEC server to support DNS over SCTP.

Shouldn't be difficult. I'm not much into either technology, but since 
SCTP can be tunneled through UDP, it should be possible to retrofit 
SCTP adoption onto an existing DNS implementation. On an OS that 
provides SCTP natively, a module inserted between the DNS daemon and 
its UDP sockets may operate the UDP/SCTP conversion when the remote 
hosts support it. Then, it would just discard spurious incoming UDP 
packets, and manage keep-alive settings for SCTP connections. It can 
work on a separate host or firewall, without even recompiling the DNS 
daemon.

---

From: der Mouse <[email-masked]>
Date: Fri, 29 May 2009 11:56:13 -0400 (EDT)

>> What's synthetic about (paraphrased) "your rDNS is missing or
>> broken, so I won't listen to you"?

> * so I won't listen to you (conclusion)

That's a bit stronger than I think is justified; I know it isn't "all".
The two (botched rDNS and clue lack) correlate well enough that I find
the rule useful, but the correlation is nowhere near good enough to
justify "all".  (Their observed face exhibits clue lack, yes.  But from
my vantage point I have no way to tell whether the clue shortage is
with the host, with its provider, or what.  I have run into cases where
a clued admin is stuck behind impaired connectivity for some reason.)

> [...] land where all ISPs obey a policy of not setting rDNS, [...]
> Local ISP market should not affect the reliability of hosts operating
> in that area.

Given how tightly coupled the ISP market is to its customers, I find
that somewhat doubtful.  But until we have an example to look at, this
is speculation.

> Possibly, a good deal of ISPs do rfc2317 delegations (if the
> customers insist.)

Or just make rDNS changes on customer request, which is what the one I
work at does.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Florian Weimer <[email-masked]>
Date: Fri, 29 May 2009 21:05:14 +0200

* Douglas Otis:

> TCP is prone to DDoS attack.

Only when implemented naively.  If the client does not split the query
into two packets or artificially lowers the window size, you can
answer it without creating any state.

The argument against TCP is not the protocol.  It's just that you have
to upgrade both authoritative servers and resolvers to make it work
well.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 May 2009 16:24:21 -0700

On May 29, 2009, at 12:05 PM, Florian Weimer wrote:

> Only when implemented naively.  If the client does not split the  
> query into two packets or artificially lowers the window size, you  
> can answer it without creating any state.

Any modification to TCP that bypasses SYN/ACK handshakes for full- 
duplex data is not TCP.  Indeed, DNS could operate accepting any TCP  
packet "as-if" SYN-ACK handshakes occurred. The stack could initially  
ignore sequence numbers, and assume all DNS messages are fully  
contained within the packet, and that all messages are always frame  
aligned.

This approach omits source verification, and therefore is unable to  
mitigate spoofed reflected attacks.  The same effect could be achieved  
using EDNS0 options that extend both transaction-ids as well as packet  
size.  Of course, discovering whether a DNS server violates TCP  
protocols or implements a new EDNS0 option may also expend an  
additional exchange.  This initial exchange would determine whether  
the DNS server uses a facocta TCP or chokes on a new EDNS0 option.  Of  
course, the originating DNS client will need to retain this result to  
establish global state to avoid increased resource consumption.  The  
initial exchange would also determine whether MTU limitations or  
packet inspection on the path may also cause non-compliant packets to  
be dropped.  Any attack hammering the client may therefore induce the  
downgrading to less secure modes.

> The argument against TCP is not the protocol.  It's just that you  
> have to upgrade both authoritative servers and resolvers to make it  
> work well.

Huh? Why suggest radical changes to the TCP protocol, and then, in the  
same breath, say the problem is not the protocol?

Defending against DDoS attack was never a major consideration during  
early TCP or UDP development.  Bot-nets weren't the problem they are  
today.  Bastardizing TCP, rather than adopting properly designed  
protocols, is unlikely to provide a solutions, but instead likely to  
create new vulnerabilities.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 May 2009 16:24:21 -0700

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 May 2009 17:24:54 -0700

On May 29, 2009, at 7:33 AM, Francis Dupont wrote:

> I don't understand your argument: it seems to apply to UDP over SCTP  
> but here we have SCTP over UDP.  BTW the easiest way to convert DNS  
> over UDP into DNS over SCTP is to use an ALG (application layer  
> gateway) which in the DNS is known as a caching server (such servers  
> are already used to provide IPv4/IPv6 transport conversion).

The goal is to apply the SCTP protocol as a means to better protect  
DNS from source spoofing, resource exhaustion, reflected attack  
exploitation, and increased latency.  SCTP in any form does not  
prevent deployment of DNSSEC.  SCTP might even better facilitate  
DNSSEC than EDNS0.  Use of DNS on SCTP, even when tunneled over UDP,  
should be explored.  The issues related to DDoS risk related to cached  
macros were presented to various DNS WGs and forums.  Unfortunately,  
this DNS issue earned little respect from the proponents of the  
protocol using macros and extensive record chaining.  The prevalent  
response was to declare DNS broken by pointing to other aspects of DNS  
at risk.  SCTP seems a reasonable solution in the face of this  
neglect.  Problems are likely to grow much faster than adoption of  
DNSSEC.  In fact, adoption of DNSSEC may make some aspects of DDoS  
exploitation worse.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 May 2009 12:35:38 +0200

> that somewhat doubtful.  But until we have an example to look at, this

I agree it is speculation, but that attitude resembles too much 
other, definitely intolerable, forms of prejudice to let it grow 
silently.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 May 2009 15:15:09 +0200

On Thu, May 28, 2009 at 03:04:19PM +0200,
 Alessandro Vesely <[email-masked]> wrote 
 a message of 30 lines which said:

> enough.  

Well, in theory, it should be EDNS0 (standardized in the previous
century) but, in practice, it has deployment issues, like everything
which was invented after Jon Postel's death.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 May 2009 16:23:25 +0200

---

From: David Conrad <[email-masked]>
Date: Thu, 28 May 2009 06:45:04 -1000

> signature proves that it originated from the authoritative server.

Not quite.  The signature over the data proves that the holder of the  
private key has signed the data.  The origin of that data then becomes  
irrelevant.

> trusted channel, I can trust the data even if it isn't signed.

Not really.  You are relying on the fact that the authoritative server  
and (potentially) the channels it uses to communicate to the  
originator of the data have not been compromised.

> That's much more difficult than forging the source address of an UDP  
> packet, though.

However, pragmatically speaking, I suspect it is going to be much,  
much easier to get DNSSEC deployed than it would be to get every  
router/firewall/NAT manufacturer and network operator to support/ 
deploy SCTP, not to mention getting every DNSSEC server to support DNS  
over SCTP.

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 May 2009 12:38:56 -0400 (EDT)

transport security is pretty meaningless in the DNS world which operates
using a distributed caching system. This is why dnscurve is just an
academic experient that can never leave the lab for the real world.

Paul

---

From: David Conrad <[email-masked]>
Date: Thu, 28 May 2009 16:34:38 -1000

Doug,

On May 28, 2009, at 2:36 PM, Douglas Otis wrote:
> depends upon the thorny problem of verifying a key will be solved in  
> a practical and politically acceptable manner.

If you're talking about the 'who signs the root key' political  
problem, I would note there is already an alternative.  Folks who  
don't trust whoever signs the root can simply include the trust  
anchors from the IANA ITAR (http://itar.iana.org/).  Yes, this means  
managing (many) more trust anchors than the single root anchor, but if  
you're that worried that the Men In Black might muck with the root  
KSK, you probably prefer to verify what IANA put into the root is  
valid by hand anyway.

> This protection also requires authoritative servers to rapidly adopt  
> DNSSEC without also confronting other insurmountable deployment  
> issues.  Fool me once, shame on you.  Fool me twice...

If there are insurmountable deployment issues, then it might be worth  
raising them in the DNSEXT working group so we can all stop wasting  
our time trying to deploy DNSSEC.

> DNS.

"First, boil the ocean..."

> If so, an ability to corrupt DNS information would be greatly  
> reduced, whether data is signed or not.  In addition, SCTP can  
> safely carry larger signed results without the DDoS concerns that  
> will exist for either TCP or EDNS0 over UDP.  Deploying DNS on SCTP  
> should be possible in parallel with the DNSSEC effort.

I have no objection to anyone proposing DNS over SCTP and would agree  
there are benefits.  I am simply saying that channel security (such as  
DNS over SCTP) does not actually protect what matters, the data that  
is returned.  Specifically, if a device in the SCTP connection path is  
compromised and the data is not signed, you lose.  If the data is  
signed, it doesn't matter how you get the data or how hostile the path  
is.  Getting that data via SCTP would be fine.  But so would UDP, TCP,  
sneakernet, or IP over Carrier Pigeon.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 29 May 2009 14:14:32 +0900

Douglas Otis wrote:
    
> While DNSSEC may protect against data corruption,

So does TCP, UDP or SCTP checksum.

A problem is that such protection does not valid over a chain of
certificate authorities or caching servers.

> such protection  
> practical and politically acceptable manner.

If the protection by a chain of untrustworthy certificate authorities
of DNSSEC is practically acceptable, a protection by a chain of
untrustworthy caching servers of plain old DNS is also practically
acceptable. Moreover, plain old DNS is already practically accepted.

Though there seems to be some confusion that DNSSEC security were
end to end, below is an excerpt from an authentic document by David
Clark on how PKI, including DNSSEC, involves certificate authorities
of third parties.

http://portal.acm.org/citation.cfm?doid=383034.383037
Public-key certificates
An important role for a third party occurs when public key cryptography
is used for user authentication and protected communication. A user can
create a public key and give it to others, to enable communication with
that user in a protected manner. Transactions based on a wellknown
public key can be rather simple two-party interactions that fit well
within the end to end paradigm. However, there is a key role for a
third party, which is to issue a Public Key Certificate and manage the
stock of such certificates; such parties are called certificate
authorities. The certificate is an assertion by that (presumably
trustworthy) third party that the indicated public key actually goes
with the particular user.

So, though communication between an end user and a certificate
authority can be end to end, the entire system of PKI is not.

							Masataka Ohta

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 29 May 2009 12:27:20 +0200

On May 29, 2009, at 12:23 PM, Alessandro Vesely wrote:

> Shouldn't be difficult. I'm not much into either technology, but  
> since SCTP can be tunneled through UDP, it should be possible to  
> retrofit SCTP adoption onto an existing DNS implementation. On an OS  
> that provides SCTP natively, a module inserted between the DNS  
> daemon and its UDP sockets may operate the UDP/SCTP conversion when  
> the remote hosts support it. Then, it would just discard spurious  
> incoming UDP packets, and manage keep-alive settings for SCTP  
> connections. It can work on a separate host or firewall, without  
> even recompiling the DNS daemon.
On FreeBSD/MacOS X you can just code against the normal SCTP socket  
API and
set a sysctl that outgoing associations should be initiate via SCTP/ 
UDP/IPv[46].
For incoming associations everything is done automatically.
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2009 09:28:29 -0400 (EDT)

On Fri, 29 May 2009, Alessandro Vesely wrote:

> One has to trust each cache!

Your solution to protect the DNS is "just trust everyone"?

> Given that it is pretty easy to predict a subset 
> of the queries a given server will issue in a give time frame, using SCTP can 
> improve reliability better than adding another 32bit random number.

The source port randomization patch is not DNSSEC. DNSSEC is much more then
a 32bit random number. Please read the RFCs.

Paul

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 May 2009 15:29:58 +0200

In your previous mail you wrote:

=> with EDNS0 this is a bit more complex but IMHO this is the idea.
Note the recommended "connection management" (RFC 1025 4.2.2) suggests
multiple queries/responses too.

=> this is not a new idea but today no server or resolver implementation
supports DNS over SCTP.
I have a lot of sympathy for SCTP but for DNS we need a transaction
oriented transport, i.e., something more secure than simple stateless
query/response over UDP but without the overhead of opening and closing
TCP connections. This is a very old idea, cf. RFC 955, but as far as
I know this is still an open problem. If I am wrong (I'd like to be :-)
please request a BoF in the transport area ASAP!

=> IMHO it is far less than 10 years but arguing about this point is
out of topic.

=> TCP is very expensive in terms of resources for the server and
TCP is still vulnerable to in-the-path attacks.

   
=> DNSSEC is the only available solution which solves the problems.
Others are not available (no specification published in a standard
track RFC or simply unfeasible) or don't address the problems
(hop-by-hop security for instance, when end-to-end is needed).
Both TCP and SCTP are in the others today...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 May 2009 16:33:14 +0200

hosts support it.

=> I don't understand your argument: it seems to apply to UDP over SCTP
but here we have SCTP over UDP. BTW the easiest way to convert DNS over
UDP into DNS over SCTP is to use an ALG (application layer gateway)
which in the DNS is known as a caching server (such servers are already
used to provide IPv4/IPv6 transport conversion).

Regards

---

From: David Conrad <[email-masked]>
Date: Fri, 29 May 2009 07:31:24 -1000

Alessandro,

> One has to trust each cache!

With DNSSEC, you don't have to trust the cache since the only thing  
the miscreants who compromise the cache can do is the functional  
equivalent of removing the entry from the cache.

> Given that it is pretty easy to predict a subset of the queries a  
> given server will issue in a give time frame, using SCTP can improve  
> reliability better than adding another 32bit random number.

1) It isn't easy
2) That's not what DNSSEC does (if that's what you're implying).

>> This is why dnscurve is just an academic experiment that can never  
>> leave the lab for the real world.

Huh?  What are you talking about?

Regards,
-drc

---

From: Francis Dupont <[email-masked]>
Date: Sat, 30 May 2009 22:31:59 +0200

=> I keep this because your answer is not about this...

   The goal is to apply the SCTP protocol as a means to better protect  
   DNS from source spoofing, resource exhaustion, reflected attack  
   exploitation, and increased latency.

=> not only this is very arguable (for instance about the resource
exhaustion) but no hop-by-hop/channel security, even something as
strong as TSIG, can provide what we need, i.e., end-to-end/object
security (*).

Regards

PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 31 May 2009 08:27:07 +0900

> strong as TSIG, can provide what we need, i.e., end-to-end/object

Unless your meaning of end-to-end differs from that of David Clark,
the following argument of his paper is applicable to DNSSEC.

	http://portal.acm.org/citation.cfm?doid=383034.383037
	Rethinking the design of the Internet:
	The end to end arguments vs. the brave new world

	The certificate is an assertion by that (presumably
	trustworthy) third party that the indicated public key
	actually goes with the particular user.

	These certificates are principal components of essentially
	all public key schemes,

That is, security of DNSSEC involves third parties and is not end
to end.

> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

I'm afraid you don't know who David Clark is and how he is related
to the end to end argument.

However, all the people who are qualified to discuss end to end do
know him and his argument.

							Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Sun, 31 May 2009 11:34:00 +0200

* Douglas Otis:

> duplex data is not TCP.

>From the point of view of a compliant connection initiator, it is
hardly distinguishable from a more traditional implementation.

> mitigate spoofed reflected attacks.

The packet count would not even be higher than ordinary TCP.  If you
send a spoofed SYN to a compliant TCP server, it sends back three to
five SYN+ACKs, until it receives an ACK or an RST.  Bandwidth is a
different matter, but that could be addressed by CNAME cookies
(although Cisco's patent may apply to that).

> The same effect could be achieved using EDNS0 options that extend
> both transaction-ids as well as packet size.

Not really, EDNS0 is not suitable for communicating support of an
extended query ID.

> same breath, say the problem is not the protocol?

A lot of this has already been tried and proven in the HTTP context.
Claims that "TCP doesn't scale" or that "TCP is vulnerable to DoS
attacks" always sound very hollow to me.  DNS handles a fraction of
the requests processed by HTTP and SMTP, and yet it can't be run on
TCP for protocol reasons?  Come on.

> create new vulnerabilities.

It's already being done for HTTP, and maybe to a lesser extent, for
SMTP.

I'm not saying that it make sense to upgrade the DNS infrastructure so
that it can smoothly handle a TCP-centric load.  Such a massive
upgrade could be better used to roll out something different.  But TCP
itself is not the problem.  In fact, experience with DoS attacks
against TCP services means that you've got a portfolio of solutions to
deal with attacks, something that would have yet to be developed for a
hypothetical non-TCP transport.