Subject: [ietf-dkim] use cases for wildcard policy assertions

From: "J D Falk" <[email-masked]>
Date: Tue, 8 Apr 2008 18:50:27 -0400

So, I've been thinking about use cases for having the same ADSP (or even
a future non-author domain signing policy) for an entire tree.

One could be a free-form environment like some educational institutions
or the old demon.net, where any host might start up a mail server at any
time without talking to the admins of the root domain.  But since these
randomly initiated new servers might not be configured to sign with DKIM
correctly, the only possible record would be "unknown" -- which is, in
this case, functionally the same as having no record at all.

Another, probably more common, would be an ESP with new customers coming
online all the time -- company1.example.com, company2.example.com, and
so forth.  Perhaps they've been able to get away using wildcards thus
far.  But they'll already have a system somewhere which tracks which of
these deeper customer domains have been created, right?  So they'll
simply need to have that system update the DNS records, too.  This is
not a difficult problem -- I wrote a shell script to do it years ago,
and I'm a truly awful programmer.  Besides, they were certain to run
into it eventually.

Or there will be paranoid admins who would want to state "we don't send
any mail at all from *, unless I state otherwise in a more-specific
record."  In other words, they'd be trying to change the default state
from "unknown" to "discardable."  Some of my personal domains would
benefit from this; they're the ones where I currently have "v=spf1 -all"
records.

Did I miss any?

--
J.D. Falk
Receiver Products
Return Path 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Roland Turner <[email-masked]>
Date: Wed, 09 Apr 2008 13:13:37 +0800

> benefit from this; they're the ones where I currently have "v=spf1 -all"

This strikes me a particularly interesting one. It's not pure paranoia
so much as fail-safe / default-access-denied thinking (not that this is
access-control per se).

Setting aside questions of whether consensus has already been reached,
and the painful technical details of trying to deal with hierachies of
names rather exact matches with individual domain name, it strikes me
that any reasonable "outsider" will look at a spec that doesn't allow
him to specify in one step (rather than hopefully-correctly attached to
every single zone entry now and through all future changes) "Acme Corp's
email is ALL signed, or it's not ours" and wonder what the spec authors
were thinking.

- Roland

-- 
Roland Turner | Product Manager, RealMail | BoxSentry Pte Ltd
3 Phillip Street, #13-03 Commerce Point, Singapore 048693
Mob: +65 96700022 | Skype: roland.turner | Fax. +65 65365463
[email-masked] | www.boxsentry.com

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 09 Apr 2008 11:03:41 +0100

> email is ALL signed, or it's not ours" and wonder what the spec authors

+1

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 9 Apr 2008 12:09:52 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Roland Turner
> Sent: Wednesday, April 09, 2008 1:14 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] use cases for wildcard policy assertions
> 

I think if we go this route we need to 1) be more clear about what is
and isn't supported, and 2) include some explanation of how a subdomain
that wants a different policy (e.g. "unknown" where the parent domain is
"all", or "discardable" if it doesn't send any mail and the parent has
published a weaker practice record). 

I think part of Dave's point is that doing a good job of (1) may not be
as straightforward as it seems. 

Examples for (2) are very important in both directions (creating a
subdomain policy that is a) weaker and b) stronger than that of the
parent domain). 

Ellen

---

From: Roland Turner <[email-masked]>
Date: Thu, 10 Apr 2008 17:46:00 +0800

On Wed, 2008-04-09 at 12:09 -0400, Siegel, Ellen wrote:
...
> > [email-masked]] On Behalf Of Roland Turner
... 
> as straightforward as it seems. 

I suspect that he's concerned that, even if it were technically
feasible, it may not be so good an idea as it appears.

> subdomain policy that is a) weaker and b) stronger than that of the

Quite.

I take it that the basic technical constraint is the need to keep the
number of DNS queries to "a few" and, in particular, to establish a
constant bound, rather than, say, permit an adversary to shut down some
DNS infrastructure by sending millions of messages purporting to be from
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com?

- Roland

---

From: John Levine <[email-masked]>
Date: 11 Apr 2008 04:50:47 -0000

>email is ALL signed, or it's not ours" and wonder what the spec authors

Huh?  The DNS doesn't provide any way to do anything to an entire zone
other than AXFR.

The only way to cover an entire zone with ADSP is to create an ADSP
tree parallel to all of the names in the zone, i.e. for every
foo.bar.example.com put in a _adsp._domainkey.foo.bar.example.com.  If
the existing tree has any wildcards, you can't do it.  The current
version of ADSP has a one level tree walk that modestly decreases the
number of records you have to add, in exchange for making every ADSP
lookup more complicated.

The question that I haven't seen addressed directly is why it's so
important to provide ADSP for domains that don't exist.  Doing a DNS
lookup to see if the domain in a putative sending address exists has
been a useful anti-spam trick for a long time, far predating DKIM.
Mail filters often do that even though they don't check DKIM and don't
check ADSP.  So what's the point of importing it into ADSP?

My strong preference would be to take out all of the tree walking and
existence checking, and replace it with a note pointing out that ADSP
only applies to domains that exist.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2008 23:51:55 -0700

> tree parallel to all of the names in the zone, i.e. for every

Just to press this point about the DNS:

      zones are not a semantic construct that is visible to users of the DNS.

      In other words, they do not exist as part of the name space, per se.  They 
are strictly an administrative construct.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Apr 2008 14:16:13 -0700

Jim Fenton wrote:
> Before we get all wrapped up in a discussion about zones again, let me 
> point out that the ADSP specification does not rely on zones at all, 
> which I think you will agree is the proper treatment.

not in the current spec.  right.

i took this sequence as some bud-nipping.

> Wildcards don't do the right things, which is one reason why ADSP 
> doesn't depend on them, either.

not sure how wildcards figure into an exchange about zones, but since we are 
trying not to pursue zones, we probably don't have to worry about this point, 
either...

d/
-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 11 Apr 2008 16:37:18 -0500

> The question that I haven't seen addressed directly
 > is why it's so important to provide ADSP for domains
 > that don't exist.

Eric explained it pretty well I thought.  We need the NXDOMAIN check so 
that use of arbitrarily selected host name don't immediately defeat  ADSP.

 > check ADSP.

So?  Are you saying that because a practice is already in use it 
therefore isn't a candidate for specification?

 > So what's the point of importing it into ADSP?

The point is so we can make certain that those who aren't currently 
employing the practice will do so and to make sure that the practice 
gets itself into a standards document from this body so that we don't 
have to guess whether it's being used or not.

I honestly don't understand the resistance to something as trivial and 
well understood as an NXDOMAIN check.

Arvel

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 14:29:08 -0700

> number of records you have to add, in exchange for making every ADSP

Exactly.  That's the tradeoff we have to evaluate:  making it easier to 
publish a complete set of ADSP records vs. the complexity of the 
lookup.  The complexity of the lookup is something done by the ADSP 
implementation; an individual verifier implementing ADSP doesn't need to 
do anything special.  Whether the decrease in the number of records you 
have is modest or not depends a lot on your domain:  If you have a small 
domain, it's very modest.  But some domains have tens or hundreds of 
thousands of labels such as hostnames, and the prospect of publishing an 
ADSP record for each one is non-trivial.  These records also cache 
individually, so it might be interesting if someone spoofs a large 
number of hostnames within a domain, such as a DHCP address pool.

My opinion, of course, is that referencing the parent domain is the 
better choice than publishing the extra records.

> check ADSP.  So what's the point of importing it into ADSP?

As someone pointed out, you can interchange steps 1 and 2 in the 
specification, putting the existence check first.  And then, of course, 
you can decide that the existence check is done outside ADSP.  If the 
existence check is removed, I would advocate putting in language that 
says an existence check SHOULD be performed before doing ADSP.  Perhaps 
even a MUST, in order to make sure that a lot of unnecessary references 
to the parent aren'done.  The existence check should be shown in the 
overview document as well (and isn't currently).  I don't think that 
having the existence check in the spec is harmful, because many 
developers are going to note that they have already done one, and skip 
it, and caching will take care of those that don't remove the duplication.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 14:06:42 -0700

Dave Crocker wrote:

John Levine wrote:

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 16:19:34 -0700

> have to guess whether it's being used or not.

That's an excellent point:  I don't think that the domain existence 
check is specified anywhere, even though it is common practice.  That's 
why we need normative language requiring it, somewhere.  Whether we 
consider the check itself part of ADSP or not doesn't really matter, as 
long as it gets done.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Apr 2008 16:52:19 -0700

Jim Fenton wrote:
> That's an excellent point:  

Indeed it is.  It crystalized one of the very basic problems with our trying to 
add this mechanism.

It's called feature creep. It is also entirely outside the scope of this working 
group.

Really. It has nothing to do with DKIM and nothing to do with Author Domain 
*signing*.

Really.  A working group's protocol specification effort is supposed to be 
guided by more than a current feeling that it should tell folks what is good for 
them.

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 17:13:44 -0700

Dave Crocker wrote:
>>> gets itself into a standards document from this body so that we 
>>> don't have to guess whether it's being used or not.
>>>   
>>
> Indeed it is.  It crystalized one of the very basic problems with our 
> trying to add this mechanism.
>
> It's called feature creep. It is also entirely outside the scope of 
> this working group.
>
> Really. It has nothing to do with DKIM and nothing to do with Author 
> Domain *signing*.
>
> Really.  A working group's protocol specification effort is supposed 
> to be guided by more than a current feeling that it should tell folks 
> what is good for them.

By including my introductory comment, but not the brief accompanying 
explanation, you are quoting me out of context, which I don't appreciate.

If ADSP can depend on a well-specified requirement for checking for the 
existence of the domain, please indicate where this is specified.

If ADSP would depend on a "common practice" of checking for domain 
existence, and produces a misleading result in the absence of this 
check, then ADSP is incomplete unless it includes this.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 11 Apr 2008 23:11:14 -0500

> It's called feature creep. 

Hooey.

Really.

> It is also entirely outside the scope of this working group.

Substantiate this incredible claim or please stop making it.  It's just 
plain false.

> Really. It has nothing to do with DKIM and nothing to do with Author 

We're talking about an algorithm for what to do in the absence of DKIM 
and signing.  The NXDOMAIN check is a piece of that algorithm that makes 
it work.  Without it, our purpose is trivially defeated.  Why can't you 
see that?

> Really.  A working group's protocol specification effort is supposed to 
> be guided by more than a current feeling that it should tell folks what 
> is good for them.

That's not fair.  Really.  Really, really.

I and others have offered concrete specifics on why we know this is a 
critical piece of the algorithm.  That's not guidance by "current 
feeling" or a desire to "tell folks what is good for them."

Arvel

---

From: John Levine <[email-masked]>
Date: Fri, 11 Apr 2008 23:42:46 -0400 (EDT)

I said:
>> The current version of ADSP has a one level tree walk that modestly 
>> decreases the number of records you have to add, in exchange for making 
>> every ADSP lookup more complicated.

Jim said:
> ... Whether the decrease in the number of records you have is modest or 
> not depends a lot on your domain:  If you have a small domain, it's very 
> modest. But some domains have tens or hundreds of thousands of labels 
> such as hostnames, and the prospect of publishing an ADSP record for 
> each one is non-trivial.

Indeed it's non-trivial if your DNS managers aren't capable of automating 
it, but if your domain names are more than one deep, it's also mandatory.

The current optimization is useful IF you have a lot of first level 
subdomains AND you don't have any lower level subdomains AND you have 
hostile DNS managers who won't automate the process of creating the ADSP 
records.  While I don't doubt that there are domains like that, it strikes 
me as a severe case of premature optimization to design with them in mind.

> These records also cache individually, so it might be interesting if 
> someone spoofs a large number of hostnames within a domain, such as a 
> DHCP address pool.

Assuming the cache does proper RFC 2308 negative caching, if you have an 
explicit record, it'll be cached, if not you'll have a negative cache 
entry where the record would have been, along with a second lookup (which 
with luck will hit the cache) for the upper level record.  The load and 
performance with the tree walk is if anything marginally worse.  I also 
note that a lot of DHCP address pools have names several levels deep, e.g. 
cpe-74-72-193-44.nyc.res.rr.com, so the tree walk would be of minimal help 
anyway.

> specification, putting the existence check first.  And then, of course, you 
> can decide that the existence check is done outside ADSP.  If the existence 
> check is removed, I would advocate putting in language that says an existence 
> check SHOULD be performed before doing ADSP.

That seems reasonable.  My objection (and I think also Dave's) is not that 
it's a bad idea, but that it's not part of DKIM or ADSP.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Apr 2008 22:38:17 -0700

> it's a bad idea, but that it's not part of DKIM or ADSP.

Just to get this on the record, yes, I think it's out of scope, but in the 
interest, I think it would be no worse than benign to have a non-normative 
statement, along the lines of:

      "In the absence of an ADSP record, attempted use of unregistered domain 
names can be detected by querying the DNS for the domain name and treating a 
returned NXDomain as an unauthorized use."

This provides the desired education without confusing things with ADSP and 
without getting overly lofty about the wonderfulness of the mechanism.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 22:47:50 -0700

John Levine wrote:
>>> decreases the number of records you have to add, in exchange for 
>>> making every ADSP lookup more complicated.
>
> Jim said:
>> ... Whether the decrease in the number of records you have is modest 
>> or not depends a lot on your domain:  If you have a small domain, 
>> it's very modest. But some domains have tens or hundreds of thousands 
>> of labels such as hostnames, and the prospect of publishing an ADSP 
>> record for each one is non-trivial.
>
> Indeed it's non-trivial if your DNS managers aren't capable of 
> automating it, but if your domain names are more than one deep, it's 
> also mandatory.

You do need to publish records for the immediate parents of all names 
you intend to cover, so if you have a.foo.example.com you need to 
publish at least foo.example.com.  But this is still a substantial 
savings over having to publish for all leaf nodes, because it is the 
rare domain that has multilevel names that don't have some relationship 
to each other, i.e., it's rare to have a.foo.example.com and not (other 
things).foo.example.com.  So you're saving by covering all of 
foo.example.com with a single record.

> hostile DNS managers who won't automate the process of creating the 
> ADSP records.  While I don't doubt that there are domains like that, 
> it strikes me as a severe case of premature optimization to design 
> with them in mind.

I'm not aware of any tools currently in existence that would automate 
this process, so the practical requirement to have such tools would be a 
major obstacle to getting complete ADSP coverage for many large 
domains.  As I said above, the optimization is still effective if you do 
have lower level subdomains; it just requires the publication of ADSP 
records for those subdomains that would in turn cover the terminal nodes 
within those subdomains.  This is still a very substantial optimization 
in most cases, even though it does not optimize to publishing just one 
record.

> Assuming the cache does proper RFC 2308 negative caching, if you have 
> an explicit record, it'll be cached, if not you'll have a negative 
> cache entry where the record would have been, along with a second 
> lookup (which with luck will hit the cache) for the upper level 
> record.  The load and performance with the tree walk is if anything 
> marginally worse.  I also note that a lot of DHCP address pools have 
> names several levels deep, e.g. cpe-74-72-193-44.nyc.res.rr.com, so 
> the tree walk would be of minimal help anyway.

The caching argument was not well thought out, I'll admit.  I'm not too 
worried about the load if it's only marginally worse, if it makes it 
practical for domains to publish ADSP records.  But the name 
cpe-74-72-193-44.nyc.res.rr.com could be covered by an ADSP record 
published at nyc.res.rr.com, which would cover a large number of such 
names with a single record, so there is a substantial savings in records 
published.

>> specification, putting the existence check first.  And then, of 
>> course, you can decide that the existence check is done outside 
>> ADSP.  If the existence check is removed, I would advocate putting in 
>> language that says an existence check SHOULD be performed before 
>> doing ADSP.
>
> That seems reasonable.  My objection (and I think also Dave's) is not 
> that it's a bad idea, but that it's not part of DKIM or ADSP.

My problem is that the existence check isn't specified anywhere else, so 
should be specified in ADSP.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 12 Apr 2008 09:12:58 +0200

Jim Fenton wrote:
 
> If ADSP can depend on a well-specified requirement for
> checking for the existence of the domain, please indicate
> where this is specified.

There is no requirement to check the existence of domains
in originator addresses.  I *think* that 2822upd or 2821bis
require that originator addresses are reachable, but maybe
I'm wrong, please check it if you want it as justification
for step 2 in the draft.

 Frank

---

From: John Levine <[email-masked]>
Date: 12 Apr 2008 16:10:29 -0000

>> checking for the existence of the domain, please indicate

The current 2821bis draft says in sec 5:

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e.  A or AAAA) RRs (as discussed
   in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used. 

The 2822upd draft says in sec 3.4.1:

      Note: A liberal syntax for the domain portion of addr-spec is
      given here.  However, the domain portion contains addressing
      information specified by and used in other protocols (e.g.,
      [RFC1034], [RFC1035], [RFC1123], [I-D.klensin-rfc2821bis]).  It is
      therefore incumbent upon implementations to conform to the syntax
      of addresses for the context in which they are used.

and a little later

   The domain portion identifies the point to which the mail is
   delivered.  In the dot-atom form, this is interpreted as an Internet
   domain name (either a host name or a mail exchanger name) as
   described in [RFC1034], [RFC1035] and [RFC1123].  In the domain-
   literal form, the domain is interpreted as the literal Internet
   address of the particular host.  In both cases, how addressing is
   used and how messages are transported to a particular host is covered
   in separate documents such as [I-D.klensin-rfc2821bis].  These
   mechanisms are outside of the scope of this document.

So the intention is clearly that the domains in addresses are supposed
to exist, but I don't see it in a MUST sentence.  I'll ask whether
that's deliberate, or it was so obvious that they didn't think it was
worth mentioning.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2008 14:14:09 -0700

>that's deliberate, or it was so obvious that they didn't think it was

There is a presumption that a domain must exist if we want to use it 
for addressing.  ADSP does not look at the question from the same 
angle as RFC 2821 and RFC 2822.  We can infer from these two RFCs, 
and the ones they refer to, whether a domain exists.  From there, we 
can outline a procedure to protect such domains.

We have to extrapolate from there and cover domains (i.e. 
sub-domains) that don't exist if they can be used to circumvent ADSP.

Regards,
-sm

---

From: Roland Turner <[email-masked]>
Date: Mon, 14 Apr 2008 11:03:35 +0800

> me as a severe case of premature optimization to design with them in mind.

It's equally a KISS thing.

The current design is a complicated tradeoff to cope with an O(k)
requirement for DNS querying. This is unfortunate, it would be desirable
for an "obvious" and simple requirement to be simple to implement. This
is not premature optimisation, it's just robust design.

(Still aware that there isn't a good way to do what I'm getting at.)

- Roland

---

From: Roland Turner <[email-masked]>
Date: Mon, 14 Apr 2008 10:42:52 +0800

> Huh?  The DNS doesn't provide any way to do anything to an entire zone

You're confusing "commercial" concerns about [anti-]spoofing with
"engineering" concerns about what the DNS infrastructure can do.

The concern that I'm raising is about likely perceptions by people who
do _not_ have a detailled working knowledge of DNS and the
potentially-surprising consequences of its federated architecture. As it
stands, it looks absurd. I am not advocating making ADSP do something
that DNS cannot do, merely that an apparently astonishing oversight be
addressed. At this point, this probably amounts to a non-normative
paragraph making clear the rather limited cover/protection that ADSP
will, albeit with good cause, be able to provide.

> the existing tree has any wildcards, you can't do it.

I'll address this, but not because I'm advocating the alternatives,
merely because they're design choices that have apparently been
rejected:

- Another way to have ADSP to cover an entire hierachy is to allow a
policy specified at any level in the hierachy override policy specified
at any higher level. The [entirely sound] basis for rejecting this is
that it requires a tree-walk, albeit a limited one (O(n), but the
requirement is O(k)).

- Another way to have ADSP cover an entire hierachy is to use knowledge
about rarely-changing registrar practices to work out where in the tree
the highest "delegated to an organisation" node is and to query just
that node for ADSP. (See also the tables of such practices maintained by
web-browsers to limit the cross-domain propogation of cookies.) This
meets the O(k) requirement, causes the spec to do what non-engineers are
likely to expect of it ("if anyone sends email purporting to be from our
'domain' but which we didn't send, the receiver will be able to realise
that with certainty") but imports a requirement for implementors to use
a database of information about registrar practices which (a) adds
complexity, (b) adds a little fragility in that this may change without
notice and (c) may well exclude this sort of cover from some domains
entirely. (Actually, (c) is not so bad; it's akin to the impossibility
of getting SSL certs for domains under some ccTLDs because of registrar
behaviour/situation.)

> check ADSP.  So what's the point of importing it into ADSP?

ADSP's adoption as it stands will provide an incentive to locate A
records which, through administrator error, lack an associated ADSP
entry. This is not to say that a protocol should survive all
administrator errors, but introducing this sort of fragility is
unfortunate.

> only applies to domains that exist.

Quite. This works for RealMail (we see ADSP as a means to put teeth onto
whitelists), but I suspect that it will harm ADSP's adoption more
generally.

- Roland

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Apr 2008 12:55:20 +0200

> it's a bad idea, but that it's not part of DKIM or ADSP.

Once upon a time in this organization we had no problem reiterating such 
practices with a mind toward not having to keep the reader bouncing 
between documents to understand exactly how best to implement a 
feature.  So let's put this in terms of benefit versus harm.  The 
benefit is just as I described.  What is the harm?

Eliot

---

From: [email-masked] (Wietse Venema)
Date: Mon, 14 Apr 2008 09:53:28 -0400 (EDT)

+1

It's unfortunate that DNS won't let us specify ADSP policies that
cover only non-existent originator domain names, but wishing for
such an ability does not mean that we suddenly can.

The NXDOMAIN result for the originator domain cannot(*) correspond
with an ADSP policy (one of "unknown" / "all" / "discardable"),
and therefore it cannot be part of ADSP.

	Wietse

(*) Otherwise we could declare 99.9999% ADSP deployment today.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J D Falk" <[email-masked]>
Date: Mon, 14 Apr 2008 12:40:12 -0400

>>> course, you can decide that the existence check is done outside
ADSP. 
>>> If the existence check is removed, I would advocate putting in
>>> language that says an existence check SHOULD be
> performed before doing ADSP.

+1

> cover only non-existent originator domain names, but wishing for such
> an ability does not mean that we suddenly can.
> 
> with an ADSP policy (one of "unknown" / "all" / "discardable"), and
> therefore it cannot be part of ADSP.

Would it be an acceptable compromise to add the above (or similar) to
the draft?

> (*) Otherwise we could declare 99.9999% ADSP deployment today.

Hmm, maybe we should do that instead....

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 17:58:19 +0000

> To: [email-masked]
> Date: Mon, 14 Apr 2008 09:53:28 -0400
> From: [email-masked]
> Subject: Re: [ietf-dkim] protecting domains that don't exist
> 
> John Levine:

-1 I disagree. Having the NXDOMAIN check makes thh scoping boundaries of ADSP explicit in the discovery algorithm. That is why I advocated making it step 1. Anything that fails that test is explicitly outside the scope of what ADSP covers. Without this explicit scope boundary the behavios of different systems querying this data would become very unpredictable. With the scope boundaries as defined by step 2 it is unequivocal that any query for something that does not exist cannot be valid within ADSP.

> and therefore it cannot be part of ADSP.

If this test were applied to every RFC then no RFC could ever formally state what set of data it applies to (since obviously that counter set would be something that would not have a valid response within that context). If we applied this same test to DNS for example would we even have NXDOMAIN (or "Name Error" as its called in rfc 1035) as a response code at all?

Would it be better if "error" were a specifically defined result in addition to "unknown" / "all" / "discardable"?

> http://mipassoc.org/dkim/ietf-list-rules.htm

_________________________________________________________________
More immediate than e-mail? Get instant access with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 14 Apr 2008 21:14:05 +0200

<[email-masked]> wrote:

> Would it be better if "error" were a specifically defined
> result in addition to "unknown" / "all" / "discardable"?

The fourth bullet in chapter 3.2 "ASP results" offers "the
domain does not exist" after "unknown"/"all"/"discardable".

I-D.kucherawy-sender-auth-header chapter 2.4.2 "ASP results"
lists this as "nxdomain".  IMHO good enough, or do you have
something else in mind ?  Let's s/ASP/ADSP/g + WGLC, s.v.p.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Apr 2008 11:06:05 -0700

On Apr 14, 2008, at 6:53 AM, Wietse Venema wrote:

>>> ADSP.  If the existence check is removed, I would advocate putting  
>>> in language that says an existence check SHOULD be performed  
>>> before doing ADSP.
>>
>> That seems reasonable.  My objection (and I think also Dave's) is  
>> not that it's a bad idea, but that it's not part of DKIM or ADSP.
>
> +1
>

RFC 2822 does not depend upon SMTP as being the message exchange  
protocol.  In addition, future message exchange protocols may depend  
upon different address resolution protocols, such as PRNP.  PPNP  
avoids any reliance upon DNS, for example.  Any protocol that might  
replace DNS may also adopt a strategy of DNS independence.  Unless  
ADSP specifies policies are limited to SMTP, it would be incorrect to  
conclude existence checks can or should depend upon DNS resource  
records.

> therefore it cannot be part of ADSP.

Even a domain's existence can not depend upon NXDOMAIN results.  This  
negative assertion depends upon the lack of wildcard use by the  
domain, network provider, and TLD provider.  Such reliance seems  
highly problematic.

ADSP should make a statement that only _SMTP_ message exchanges are  
protected by policy assertions.  By specifying which transport is  
being protected, then existence checks can depend upon MX or A  
resource records being found in DNS.  These checks are common for  
RFC2821 MailFrom addresses.  However, ADSP is assuming this existence  
checking scheme can extend to an _unspecified_ address space.  ADSP is  
the only place where transport protection can be specified.  By  
declaring the address space pertains to specifically SMTP exchanged  
messages, then SMTP discovery records can confirm existence or the  
apparent absence of SMTP related domains.  Do not assume the lack of  
NXDOMAIN confirms existence.  In addition, NXDOMAIN does not confirm  
non-existence, even when limited to SMTP.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Mon, 14 Apr 2008 15:39:13 -0400 (EDT)

> something else in mind ?  Let's s/ASP/ADSP/g + WGLC, s.v.p.

Sounds reasonable. I expect many will implement NXDOMAIN as a
fourth ADSP lookup result in some way or another. 

This explains more easily than my earlier claim (an NXDOMAIN result
cannot correspond with one of "unknown" / "all" / "discardable").

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2008 13:02:25 -0700

Sorry for being confused, but I now can't tell whether the focus is on an 
NXDomain for the _adsp.<domain> string that is queried for ADSP, or the <domain> 
name to which it is associated.

These are separate queries.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 14 Apr 2008 20:52:43 -0000

>"engineering" concerns about what the DNS infrastructure can do.

Not really.  I'm talking about what a DNS based system like ADSP can
do rather than what some other hypothetical super duper anti-badness
system might do.

>- Another way to have ADSP to cover an entire hierachy is to ...

Yes, there's a variety of hacks that would sorta kinda give you
subtree coverage.  To summarize lengthy discussions, they all suffer
from not really working (lists of known delegation points), not
working with some widely used software (zone cuts), not matching the
actual administrative organization of the DNS (zone cuts again), being
easily circumvented (limit tree walk to N levels), or usually a
combination of the above.

It is hardly a secret that spammers quickly adapt to any anti-spam
measures, so all this would do is to encourage them to exploit the
holes that the sorta kinda doesn't handle, while simultaneously
leading to stupid fights of the kind seen with SPF in which SPF
advocates claim that well established mail techniques are "forgery"
because SPF can't handle them.

>administrator errors, but introducing this sort of fragility is

They can already use random names with A records to defeat checks for
non-existent domains, so I don't see how this makes the situation
worse.

Two more observations: One is the assumption that mail from subdomains
is somehow automatically equivalent to mail from the enclosing domain.
I don't see any reason for this to be true.  I have one opinion about
mail from [email-masked], and a rather lower opinion of mail from
[email-masked], without needing any help from ADSP.

The other is that if you're so desperate to provide complete ADSP
coverage of subdomains, you can do it right now with a specialized DNS
server that does the equivalent of synthesizing names from
_adsp._domainkey.*.example.com.  This is no worse a hack than the
sorta kinda approaches, but unlike all of them, it would actually
work.

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 15 Apr 2008 00:04:16 +0200

Dave Crocker wrote:

> I now can't tell whether the focus is on an NXDomain for the
> _adsp.<domain> string that is queried for ADSP, or the <domain> 

For dom.example following draft-ietf-dkim-ssp-03#section-4.2.2:

1: dig -ttxt _adsp._domainkey.dom.example. : NXDOMAIN => try 2 + 3
2:                   dig -tmx dom.example. : NXDOMAIN => "nxdomain" 
3:     dig -ttxt _adsp._domainkey.example. : NXDOMAIN => "unknown"

> These are separate queries.

And separate results, yes.  Steps 1 and 2 could be swapped, and
step 3 is rather dubious, a slightly different approach could be:

1'                   dig -tmx dom.example. : NXDOMAIN => "nxdomain"
2' dig -ttxt _adsp._domainkey.dom.example. : NXDOMAIN => "unknown"

 Frank

---

From: [email-masked] (Wietse Venema)
Date: Tue, 15 Apr 2008 06:58:31 -0400 (EDT)

Dave Crocker:
> Sorry for being confused, but I now can't tell whether the focus
> is on an NXDomain for the _adsp.<domain> string that is queried
> for ADSP, or the <domain> name to which it is associated.

I am talking about DNS lookup #2 in ADSP: the author domain.

_adsp.domainkey.example.com IN TXT (NXDOMAIN -> "unknown").
example.com A IN                   (NXDOMAIN -> "nxdomain").

By including "nxdomain" as a verifier result we can eliminate
a confusion and frustration.

	Wietse

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 15 Apr 2008 11:59:00 +0100

On Mon, 14 Apr 2008 18:58:19 +0100, <[email-masked]> wrote:

>> course, you
>> that
> -1 I disagree. Having the NXDOMAIN check makes thh scoping boundaries of  
> ADSP explicit in the discovery algorithm. That is why I advocated making  
> it step 1. Anything that fails that test is explicitly outside the scope  
> of what ADSP covers. Without this explicit scope boundary the behavios  
> of different systems querying this data would become very unpredictable.  
> With the scope boundaries as defined by step 2 it is unequivocal that  
> any query for something that does not exist cannot be valid within ADSP.
>
Exactly. It is essential that the check be done, otherwise you don't even  
know whether ADSP is applicable or not.

And if it turns out that ADSP is not applicable, then the reader of the  
standard is entitled to ask "So what am I meant to do now?". To which we  
should at least give a minimal answer such as "This document cannot  
prescribe what action the verifier should take next, but it is not  
precluded that, as a matter of local policy, it might treat it as  
suspicious/discardable/whatever-euphemism-we-have-decided-upon".

And then, in the Security Considerations section you point out the  
opportunities for scammers that may be exploited if the verifier does  
nothing at all in this situation.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 15 Apr 2008 12:14:12 +0100

> [email-masked], without needing any help from ADSP.

OTOH, the converse is likely to be relevant to quite a lot of domains,  
even if it does not apply to aol.com.
> sorta kinda approaches, but unlike all of them, it would actually

Yes, that look interesting. But presumably it is more or less equivalent  
to doing the full tree walk and then cacheing the result (being careful to  
observe TTL).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 15 Apr 2008 12:09:11 +0100

> conclude existence checks can or should depend upon DNS resource

But how do you know which protocol the message was written for?

If it arrives at your site via SMTP, then you should apply the ADSP rules  
appropriate to SMTP. If it actually started life being transported by  
XXTP, then you just have to assume that the XXTP to SMTP gateway had fixed  
it up (e.g by not letting it through at all if it was going to violate  
someone's policy).

Conversely, if it arrives at your site via XXTP, then it may or may not be  
worth trying ADSP on it (depending on whether or not you have DNS access).  
It is again really a matter for any earlier SMTP to XXTP to have sorted  
the matter out (e.g. by verifying it and not passing it on if it failed).

Just think in terms of "XXTP" == "Carrier pigeon" :-) .

---

From: John Levine <[email-masked]>
Date: 15 Apr 2008 18:07:53 -0000

>even if it does not apply to aol.com.

Really?  Can you provide some examples of domains that use so many
subdomains for mail that it's impractical to cover the ones they use
individually?  (Not counting wildcards, we know that's a swamp.)  For
the domains I know, the mail comes from one or a handful of fixed
subdomains, and any random subdomain is bogus.

OK, please provide a list of such domains and we can special-case them.

>> , you can do it right now with a specialized DNS server

Well, no.  If you will review prior messages, this argument was about
ADSP coverage of domains that don't exist.  Covering domains that do
exist is straightforward, give or take the known wildcard problems.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Apr 2008 13:19:40 -0700

On Apr 15, 2008, at 4:09 AM, Charles Lindsey wrote:

>> protocol.  In addition, future message exchange protocols may  
>> depend upon different address resolution protocols, such as PRNP.   
>> PPNP avoids any reliance upon DNS, for example.  Any protocol that  
>> might replace DNS may also adopt a strategy of DNS independence.   
>> Unless ADSP specifies policies are limited to SMTP, it would be  
>> incorrect to conclude existence checks can or should depend upon  
>> DNS resource records.
>
> If it arrives at your site via SMTP, then you should apply the ADSP  
> rules appropriate to SMTP. If it actually started life being  
> transported by XXTP, then you just have to assume that the XXTP to  
> SMTP gateway had fixed it up (e.g by not letting it through at all  
> if it was going to violate someone's policy).

SMTP only defines "MAIL FROM" as an SMTP suitable email-address.   
Email-addresses contained within the RFC2822 headers may adopt  
different regimes pertaining to different address resolution or  
transport protocols.  In addition, DKIM is not limited to an email  
address suitable for SMTP.  One might assume any email-address signed  
by DKIM is suitable with SMTP.  However, a transport protocol  
transition will likely involve transport conversion gateways.

> Conversely, if it arrives at your site via XXTP, then it may or may  
> not be worth trying ADSP on it (depending on whether or not you have  
> DNS access). It is again really a matter for any earlier SMTP to  
> XXTP to have sorted the matter out (e.g. by verifying it and not  
> passing it on if it failed).

For example, assume XXTP uses a different discovery method from that  
of SMTP.  To clarify a protocol dependence, email-addresses using a  
new protocol might include a postfix label of 'xxtp', such as "[email-masked] 
".  Here, DKIM could establish associations between the different name  
spaces.  Unfortunately, attempts at applying an 'existence' test to  
support ADSP From header compliance would also make addresses suitable  
for different transport protocols fragile when carried over SMTP.

So, ADSP must either assume email-addresses within the From header are  
suitable for use with SMTP, and then check for SMTP specific DNS  
resource records, or require each domain to publish policy resource  
records.

Although there is a difference between accounts.big-bank.com and big- 
bank.com, this difference enables a fair amount of spoofing.  There  
are no practical limits that could be applied to domain tree walking,  
since us.accounts.big-bank.com also represents a similar risk.   
NXDOMAIN, as a means to circumvent domain tree walking is problematic  
when a domain, network provider, or TLD provider make use of  
wildcards.  NXDOMAIN also assumes _all_ email-addresses contained  
within the From header, are suitable for some undefined transport that  
also depends upon DNS.  While this assumption is often correct, making  
this assumption a requirement must be deliberate, where this will  
affect SMTP overall extensibility.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Apr 2008 00:36:09 +0200

Douglas Otis wrote:

> ADSP must either assume email-addresses within the From header are  

Don't think so, "domain does not exist" is general enough.  Some
mechanism to discover a say jabber server might use SRV and NAPTR
magic, but if the domain doesn't exist there is also no magic to
worry about.

And ADSP is for RFC 2822 messages, not IM, SIP, or what you have.

If there's a problem (apart from step 3) I think the draft needs
to mention that domain literals should get ADSP result "unknown".

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Apr 2008 16:42:09 -0700

On Apr 15, 2008, at 3:36 PM, Frank Ellermann wrote:

> If there's a problem (apart from step 3) I think the draft needs to  
> mention that domain literals should get ADSP result "unknown".

This is still assuming use of DNS in conjunction with some future  
transport.  PNRP would be an example of name resolution services fully  
independent of DNS.  Not to recommend PRNP, this example only suggests  
the possibility.  It seems using DNS to assert policy necessitates use  
of DNS by all possible transports.  Unless consensus surrounding ADSP  
being forever linked to SMTP/DNS can be established, an assumption of  
'existence' checks seems rather dubious.  The NXDOMAIN existence check  
also ignores issues related wildcards which may be beyond the control  
of the originating domain.  It is rather ironic a well considered  
alternative policy scheme depended upon use of wildcards and  
publishing records at every node blocking the wildcard.

ADSP policy should state it only applies to SMTP, where at least SMTP  
discovery records can replace dependence upon the questionable return  
of NXDOMAIN.  Requiring MX records be published in conjunction with  
policy records also sets an upper limit on the number of policy  
records transactions any future SMTP policy may require.  Without an  
MX, assume no policy.  Without an MX or A record, assume no SMTP  
relevant messages relate to this domain.  Messages over other  
transports would need to establish different criteria (policies)  
possibly in conjunction with their discovery mechanisms.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Apr 2008 04:33:19 +0200

Douglas Otis wrote:
 
> This is still assuming use of DNS in conjunction with some
> future transport.

Yes, ADSP is published using DNS, and it's about "mail", the
abstract says.  ADSP flags in Fido nodelists for the purposes
of Fidomail is not discussed in RFC 5016 (sorry, couldn't
resist after you forced me to figure out what "PNRP" is ;-)

> It seems using DNS to assert policy necessitates use of DNS
> by all possible transports.

When I mentioned missing domain literals I meant it, but in
essence, yes, the format of mail addresses in 2822upd is for
DNS lookup, not for Fido, UUCP, or X.500.

> Unless consensus surrounding ADSP being forever linked to
> SMTP/DNS can be established, an assumption of 'existence'
> checks seems rather dubious.

DKIM isn't bound to SMTP, and existence checks for something
that's no domain might not need DNS.  But the discussed ADSP
draft wants us to look up _adsp._domainkey.example. in DNS
if example. exists in DNS (swapping steps 1 and 2).  

Let's solve problems with completely different technlogies
later, and after we've seen that ADSP makes sense for email,
that will take more than a year.  
  
> The NXDOMAIN existence check also ignores issues related
> wildcards

There are no wildcard issues I'm aware of.  Nothing outside
of a zone, neither below nor above it, can create wildcards
affecting the zone.  Please correct me if that's wrong, and
give an example of what you have in mind...  

> It is rather ironic a well considered alternative policy 
> scheme depended upon use of wildcards and publishing 
> records at every node blocking the wildcard.

...dunno what you mean.  A single existing node blocks any
wildcard above it for the complete subtree where it is the
root, doesn't it ?  If you are interested in domain.example.
make sure that it has an A or MX or whatever, and there is
no wildcard that could affect anything below domain.example.

Skipping your 2821bis rant, I supported you as good as I
could, when Keith gave up the battle was lost from my POV.

 Frank

---

From: <[email-masked]>
Date: Tue, 15 Apr 2008 18:50:09 -0400

This discussion about how to handle non existent domains should be relabeled Schroedinger's ADSP

-----Original Message-----
From: [email-masked] on behalf of Frank Ellermann
Sent: Tue 4/15/2008 6:36 PM
To: [email-masked]
Subject: Re: [ietf-dkim] protecting domains that don't exist

 Frank

---

From: John Levine <[email-masked]>
Date: Wed, 16 Apr 2008 02:12:06 -0400 (EDT)

> Now, I have no idea what limits were placed on this capability by provisioning
> systems. What I do know is that several customers used this feature to create
> very large numbers of subdomains. (I know this because this particular usage
> exposed several bugs.)
>
> Another thing that's surprisingly common is for sites to have very large
> numbers of explicitly configured domains and subdomains - like on the order of
> tens of thousands.

Gee, some actual real life experience -- how refreshing!

Let's assume for the purposes of argument that such a site wants to use 
DKIM and ADSP.  Presumably there's some set of tools to manage the DNS for 
the umpteen thousand subdomains.

Hypothesis A: They'll update the tools to create matching ADSP and perhaps 
DKIM key records for the domains they use, so clients can just check the 
ADSP for whatever domain is on the From: line.

Hypothesis B: The tools can't do it, they'll only be able to stick in a 
few hand-crafted DKIM key and ADSP records for upper level domains, so 
ADSP clients checking lower level subdomains will have to look around the 
tree and find those records.

The current ADSP draft is written with an eye toward B, but it seems to me 
that A is at least as likely.  What does your experience suggest?

R's,
John

---

From: [email-masked]
Date: Tue, 15 Apr 2008 21:26:39 -0700 (PDT)

> subdomains, and any random subdomain is bogus.

First of all, let me state up front that I have no skin in this particular game
and therefore don't feel strongly about this issue one way or the other.

That said, I do have a data point to offer here. Some years ago we inherited an
LDAP schema from a previous product incarnation. The schema was designed to
support complete provision of email through LDAP for ISPs and large enterprises
and it turned out to be surprisingly tricky and complex - when I first looked
at it I thought it was way too complex. But as I started seeing actual customer
usage I realized that most of it's capabilities were there for a reason. I also
realized that the attempt to standardize this sort of thing in the IETF (the
LASER project) was overly simplistic to the point of being of very limited
value.

One of the key features of this schema turned out to be uplevel domain
matching. For example, if there's a domain entry for example.com, subdomains of
example.com are also matched. (Or not - it turns out you want this to be
controllable on a domain-by-domain basis. And of course an explicit entry for
foo.example.com matches before the example.com entry does.) This in turn means
all it takes to create a subdomain is to have an address in a user entry
specifying that subdomain - very low overhead.

Another thing that's surprisingly common is for sites to have very large
numbers of explicitly configured domains and subdomains - like on the order of
tens of thousands. (This one came to my attention because of an issue with
fetching all attributes of a domain from the directory server. It turns out
that there were some performance issues when virtual attributes or so-called
class-of-service attributes are used and there are lots of entries of the same
type as the one you are reading. This and several other factors led to a total
rewrite of our domain lookup code.)

It gets worse. Another characteristic of the original implementation of this
was that if a user's entry had an address of the form [email-masked], this
would also match [email-masked] for any value of "foo". I thought this
was a bug so I didn't implement it. Mistake: At least one customer relied on
this feature to allow use of essentially arbitrary subdomains! I thought this
was stupid as hell at the time and still do, but the fact remains we had to add
support for it. (And yes, it is off by default.)

Want more? Another feature was so-called "virtual domains". These are domains
that only exist as attributes on user entries - there's no separate entry in
the directory for the domain at all. We ended up having to implement this as
well, but we've managed to wean most sites off of it, mostly because there are
some access control issues surrounding this model that are very hard to get
right.

Of course this is just my own experience. It may be the that the handful of
sites I have encountered doing this sort of thing are the only ones on the
planet that are doing it. Or it could be that this practice isn't all that
uncommon. I've pointed out previously the risks of assuming that our individual
experiences reflect any real understanding of what's out there.

FWIW.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Apr 2008 10:53:13 +0100

Hi Ned,

[email-masked] wrote:
> That said, I do have a data point to offer here. 

Interesting cases. Two questions - a lot of that sounds
like stuff they did for intra-enterprise purposes that
might not be visible in the external DNS or in emails
that got sent "outside" - is that right or wrong?

Second one: (more for the group than just you) if the
answer above is "right," would it be reasonable for ADSP
to not cater for such uses?

(As an aside, regardless of where we end up with this
issue, it does sound like we'll need at least some
guidance or informative notes in the ADSP spec.)

Thanks,
Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 16 Apr 2008 12:16:53 +0100

> subdomains, and any random subdomain is bogus.

Wrong question. There may be umpteen subdomains that are not supposed to  
send mail, but that does not prevent either a misinformed user or a  
scammer creating a message with one of them in its From header. A verifier  
that recveives such a message needs to discover whether it was supposed to  
have been signed or not, and if so by whom.
> OK, please provide a list of such domains and we can special-case them.

The domain cs.man.ac.uk contains 1800 subdomains with A records. It so  
happens that they all have MX records pointing to the official  
departmental mail exchangers, but I doubt the admins for that domain will  
relish the task of creating ADSP reecords for each of them (machines can  
be added and removed on an almost daily basis). Fortunately, this tree is  
only one level deep, so the 1-level trick built into our current draft  
will cope.

Ned has posted an even worse example AIUI.

> exist is straightforward, give or take the known wildcard problems.

But those wildcard problems have not gone away. AIUI, if MX records exist  
they are solvable (so cs.man.ac.uk would be OK).

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 16 Apr 2008 12:36:16 +0100

>> if it was going to violate someone's policy).

Actually, we are looking at the wrong question.

Any RFC 2822 message might be signed (or not). But the <addr-spec>s in RFC  
2822 contain "domain"s, and I think that there is an inbuilt presumption  
that these are "domains" as understood throughout the internet, and can  
therefore be expected to be found in the DNS. TYhat is quite separate from  
the fact that they might be sent via protocols other than SMTP.

For example, a pure UUCP message would have a From header like
     From: foo!bar!baz
in which case it is not an RFC2822 message at all. Likewise a pure X.400  
message.
> transition will likely involve transport conversion gateways.

And we have to presume that the conversion gateway did the "right thing"  
with the From headers.

Moreover, the problem is worse than that. Suppose the From header was
    From: A,B,C,D
where A and B might be reachable via SMTP and C and D not so. And it might  
have
    To: E,F,G,H
where E and F were reachable via SMTP but not G and H.

Now, suppose you are the verifier at E (so it arrived via SMTP, and had  
perhaps been SMTP all along). You want to know whether it should have been  
signed by C and D.

Your move!

> "[email-masked]

It might. And then again it might not.

---

From: John Levine <[email-masked]>
Date: 16 Apr 2008 13:50:27 -0000

>be added and removed on an almost daily basis).

I wouldn't relish it either, but I don't see why the preferences of
lazy DNS admins should be a guiding design principle.  If they can add
and remove A records, why can't they add and remove ADSP records,
particularly since the process of managing the ADSP records can
presumably be completely automated?  Or if they don't care enough to
manage the ADSP records, why is that our problem rather than their
problem?

> Fortunately, this tree is only one level deep, so the 1-level trick
> built into our current draft will cope.

That's nice, but there are places where they're more than one level
deep and the current hack doesn't work.  What then?  That's the sorta
kinda issue, it only works in some cases and when it doesn't work, you
lose.

>they are solvable (so cs.man.ac.uk would be OK).

No, if you have a wildcard MX, there's no way to cover the domains with
ADSP unless you use a stunt DNS server.

R's,
John

---

From: [email-masked]
Date: Wed, 16 Apr 2008 06:58:08 -0700 (PDT)

> Gee, some actual real life experience -- how refreshing!

Well, sort of. Our perspective on this is somewhat limited: We get told about
stuff when there's a problem. Customers as a rule don't ccntact us and say,
"This is all working great, here's all of the stuff we did". It's more like,
"Help! We did such and such and now the machine room is on fire! Help us put it
out!"

> the umpteen thousand subdomains.

I assume there is, but it isn't something we provide. (I've actually argued
that it would make sense for us to provide such a tool, possibly deriving DNS
information from what's already in LDAP, but I've gotten no traction on
developing such a thing.) 

The thought of doing  it all by manually editing BIND zone files is too
horrible to contemplate, isn't it?

> that A is at least as likely.  What does your experience suggest?

Sorry, this is one where I just don't know the answer. I'll fire off a message
to our internal support list and see what, if anything, other people here
know about DNS provisioning.

				Ned

---

From: [email-masked]
Date: Wed, 16 Apr 2008 07:13:45 -0700 (PDT)

> that got sent "outside" - is that right or wrong?

I'm pretty sure the answer is both. We've seen a couple of complex domain
setups for enterprise customers like banks that I know expose none of this to
the outside world. OTOH, when an ISP does this sort of stuff I believe it is
all part of high end service and outsourcing offerings and in that case it only
makes sense if it is public.

				Ned

---

From: "J D Falk" <[email-masked]>
Date: Wed, 16 Apr 2008 13:30:41 -0400

Ned Freed wrote:

> It's more like, "Help! We did such and such and now
> the machine room is on fire! Help us put it out!"

They actually tell you what they where doing before the fire started?
*grin*

> The thought of doing  it all by manually editing BIND zone files is
> too horrible to contemplate, isn't it?

If "do not require software changes" was ever a design goal for DKIM or
ADSP, we've already failed utterly.

You can't do DKIM without upgrading (at the very least) your MTA
software.  I wasn't following the list carefully back then -- did anyone
have a problem with that upgrade?

You may not be able to gain the benefit of ADSP for some very specific
use cases (though not all!) without upgrading DNS management software
that was written for different very specific use cases -- but you can
still use DKIM, you can still use SMTP, et cetera.

--
J.D. Falk
Receiver Products
Return Path 

work with me!
http://www.returnpath.net/careers/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Apr 2008 16:30:19 -0700

On Apr 15, 2008, at 7:33 PM, Frank Ellermann wrote:

>> transport.
> abstract says.  ADSP flags in Fido nodelists for the purposes of  
> Fidomail is not discussed in RFC 5016 (sorry, couldn't resist after  
> you forced me to figure out what "PNRP" is ;-)

Okay.

>> It seems using DNS to assert policy necessitates use of DNS by all  
>> possible transports.
>
> When I mentioned missing domain literals I meant it, but in essence,  
> yes, the format of mail addresses in 2822upd is for DNS lookup, not  
> for Fido, UUCP, or X.500.

Since it is impossible for domain literals to represent a signing  
domain for DKIM, it would seem obvious literal addressing is a matter  
not covered by ADSP.

RFC2822 specifies "Internet Domain".  While the term Internet Domain  
infers a single name space, name spaces within corresponding services  
resolving addresses and services could be introduced under differing  
TLDs.  PRNP was given as an example, since this scheme resolves  
address structures needed to navigate through gateways and tunnels.   
While this scheme is proprietary, existence of an enhanced name  
service represents a current need being fulfilled.  PRNP allows groups  
to assign "friendly names" with unique identifiers which may overlap  
DNS name space.  Even so, this name space could be defined in a  
complaint manner using a scheme like name._group for example.  With  
ADSP imposing "existence" requirements, now only DNS determines what  
is an Internet Domain.

>> Unless consensus surrounding ADSP being forever linked to SMTP/DNS  
>> can be established, an assumption of 'existence' checks seems  
>> rather dubious.
>
> DKIM isn't bound to SMTP, and existence checks for something that's  
> no domain might not need DNS.  But the discussed ADSP draft wants us  
> to look up _adsp._domainkey.example. in DNS if example. exists in  
> DNS (swapping steps 1 and 2).

Agreed, DKIM is not bound to SMTP.  The suggestion is to avoid  
conflicts by binding ADSP policy assertions specifically to email  
addresses _suitable_ for SMTP/DNS.  The current ADSP draft requires  
RFC2822 Internet Domains "exist" within DNS, which is not currently  
required.  ADSP stipulates DNS.  ADSP is to benefit SMTP.

> Let's solve problems with completely different technologies later,  
> and after we've seen that ADSP makes sense for email, that will take  
> more than a year.

Agreed.  So limit the scope of the policy assertion to just SMTP/DNS.   
Consensus should be reached about what ADSP "existence" requirements  
really imply.

>> The NXDOMAIN existence check also ignores issues related wildcards
>
> There are no wildcard issues I'm aware of.  Nothing outside of a  
> zone, neither below nor above it, can create wildcards affecting the  
> zone.  Please correct me if that's wrong, and give an example of  
> what you have in mind...

When the ADSP existence scheme depends upon an NXDOMAIN, this will  
fail to offer protections when either a network or TLD provider  
introduces wildcards, or when the domain itself uses wildcards.  By  
depending upon NXDOMAIN, ADSP protections just not possible when  
wildcards are introduced.

>> It is rather ironic a well considered alternative policy scheme  
>> depended upon use of wildcards and publishing records at every node  
>> blocking the wildcard.
>
> ...dunno what you mean.  A single existing node blocks any wildcard  
> above it for the complete subtree where it is the root, doesn't  
> it ?  If you are interested in domain.example. make sure that it has  
> an A or MX or whatever, and there is no wildcard that could affect  
> anything below domain.example.
>
> Skipping your 2821bis rant, I supported you as good as I could, when  
> Keith gave up the battle was lost from my POV.

Perhaps pride inhibits an ability to impose necessary discipline,  
similar to a proud parent ignoring their misbehaving child.  It is  
ludicrous to suggest domains publish bogus MX records to avoid  
undesired SMTP traffic, but those implementing SMTP can not be  
expected to publish valid MX records.  This is shameful.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 17 Apr 2008 04:58:01 +0200

Douglas Otis wrote:

> RFC2822 specifies "Internet Domain".

Yeah, good enough for ADSP.  There is a note in 2822upd-06:

| A liberal syntax for the domain portion of addr-spec is
| given here.  However, the domain portion contains addressing
| information specified by and used in other protocols (e.g.,
| [RFC1034], [RFC1035], [RFC1123], [I-D.klensin-rfc2821bis]).
| It is therefore incumbent upon implementations to conform to
| the syntax of addresses for the context in which they are used.

> name spaces within corresponding services resolving addresses
> and services could be introduced under differing TLDs.

They could, and they will do the right thing, or publish a
draft explaining what "the right thing" is if it's unclear.

> PRNP was given as an example, since this scheme resolves  

AFAIK MS still thinks that SenderID solved the spam problem
in 2006, everybody uses it, and nobody bothered to inform
them that they confused PRA and SPF among other things. ;-)

Seriously, you don't want to discuss the "Cesidian root"
and Apple Talk on the DKIM list, or do you ?  That's fun
stuff for edit wars in Wikipedia, or flame wars on the
Namedroppers list...

> unique identifiers which may overlap DNS name space.

...their problem, they broke it, they fix it.  Of course
odd things happen when name spaces overlap, e.g., what is
a "unique identifier" in this case ?  For a unique number
in a name space UUID take 122 SHA-1 bits, that is "better"
than 122 MD5-bits.  Some RFCs are hilarious, or I missed
the clue, completely.

> using a scheme like name._group for example.  With ADSP
> imposing "existence" requirements, now only DNS determines
> what is an Internet Domain.

Where do you want to get _adsp_.domainkey.name._group from ?
If the existence of name._group does not matter, what about
the uniqueness of _adsp._domainkey.name._group ?  And under
what circumstances would IANA survive the introduction of a
_group TLD violating RFC 1123 and my 1123-erratum ?  Don't
mess around with RFC 3696 :-(

> The suggestion is to avoid conflicts by binding ADSP policy
> assertions specifically to email addresses _suitable_ for
> SMTP/DNS.

The existence check is at worst bound to class IN (please
check this) and limited to non-existence, where SMTP, HTTP,
NNTP, etc. don't enter the picture.  FWIW "NXDOMAIN" also
means no WKS, no RP, no HINFO, no SRV (please check this).

> When the ADSP existence scheme depends upon an NXDOMAIN,
> this will fail to offer protections when either a network
> or TLD provider introduces wildcards

Not for what we are talking about.  As long as "something"
exists at claranet.de. TLD de. cannot create any wildcard 
affecting xyzzy.claranet.de., www.xyzzy.claranet.de., etc.

> or when the domain itself uses wildcards.

Yes, that's the case for xyzzy.claranet.de.  So what ?  It
is a stupid wildcard, permanently disabled due to abuse by
spammers sending more spam to @xyzzy than claranet.de was
willing to let me kill with POP3 over V.90.  (They gave up,
JFTR, but admittedly I didn't insist on reviving @xyzzy :-)

> By depending upon NXDOMAIN, ADSP protections just not
> possible when wildcards are introduced.

ADSP and DKIM are not designed for wildcard tricks, we know
this, this has nothing to do with NXDOMAIN, it is just a
consequence of using _adsp._domainkey "property-subdomain-
labels" (correct term TBD, compare Dave's draft).

 [Off Topic about 2821bis]
> It is ludicrous to suggest domains publish bogus MX
> records to avoid undesired SMTP traffic, but those
> implementing SMTP can not be expected to publish valid
> MX records.  This is shameful.

I don't disagree.  But obviously the PTB prefer to handle
it elsewhere, in separate RFCs.  

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Apr 2008 09:55:52 -0700

> | the syntax of addresses for the context in which they are used.

DNS has not been required in RFC2822, only that naming _syntax_ be  
compliant.  In the case of ADSP, DNS is mandated and even includes  
heuristics specific to DNS.

>> name spaces within corresponding services resolving addresses and  
>> services could be introduced under differing TLDs.
>
> They could, and they will do the right thing, or publish a draft  
> explaining what "the right thing" is if it's unclear.

Other naming services are being explored where naming service agility  
requires minimal dependence on service specific heuristics, AND not  
assuming _all_ Internet Domains are resolved within DNS.

>> PRNP was given as an example, since this scheme resolves address  
>> structures needed to navigate through gateways and tunnels.
>
> AFAIK MS still thinks that SenderID solved the spam problem in 2006,  
> everybody uses it, and nobody bothered to inform them that they  
> confused PRA and SPF among other things. ;-)
>
> Seriously, you don't want to discuss the "Cesidian root" and Apple  
> Talk on the DKIM list, or do you ?  That's fun stuff for edit wars  
> in Wikipedia, or flame wars on the Namedroppers list...

A proprietary scheme is not recommended, but it is not be unthinkable  
open source schemes might offer similar features, and perhaps overcome  
some of DNS's security issues as well.  Discussing naming service  
agility in the abstract is difficult.  However, it is rather clear  
ADSP has stipulated DNS and its heuristics.  ADSP should declare the  
extent of the policy and stipulate this policy _only_ relates to email- 
addresses suitable for SMTP and DNS.

> ...their problem, they broke it, they fix it.  Of course odd things  
> happen when name spaces overlap, e.g., what is a "unique identifier"  
> in this case ?  For a unique number in a name space UUID take 122  
> SHA-1 bits, that is "better" than 122 MD5-bits.  Some RFCs are  
> hilarious, or I missed the clue, completely.

In this scheme, the group accepts friendly names bound to a patented  
process of self generated identifiers and self-signed certs.  Security  
seems reliant on the group's vetting.  How much worse is this over  
BGP? : )

>> using a scheme like name._group for example.  With ADSP imposing  
>> "existence" requirements, now only DNS determines what is an  
>> Internet Domain.
>

When a name is within a different naming service, it is unlikely ADSP  
policy would be available.  The problem occurs when there is _first_ a  
negative "existence" check (NXDOMAIN).  When a domain does not exist  
within DNS, although the SMTP MAIL FROM email-address does, the  
application of ADSP policy may cause such messages to be rejected.   
Otherwise, what value would ADSP compliance offer?

> If the existence of name._group does not matter, what about the  
> uniqueness of _adsp._domainkey.name._group ?  And under what  
> circumstances would IANA survive the introduction of a _group TLD  
> violating RFC 1123 and my 1123-erratum ?  Don't mess around with RFC  
> 3696 :-(

The concern is not over naming syntax.

>> assertions specifically to email addresses _suitable_ for SMTP/DNS.
>
> The existence check is at worst bound to class IN (please check  
> this) and limited to non-existence, where SMTP, HTTP, NNTP, etc.  
> don't enter the picture.  FWIW "NXDOMAIN" also means no WKS, no RP,  
> no HINFO, no SRV (please check this).

IN class is a heuristic of DNS.  Require email-addresses governed by  
ADSP to be compliant with SMTP.  This restriction allows dealing with  
issues related to wildcards and avoids reliance upon negative  
existence checks within DNS (and DNS heuristics such as NXDOMAIN).  By  
depending upon positive existence, ADSP compliance would minimally  
indicate the From email-address is compliant with SMTP.

>> introduces wildcards
> Not for what we are talking about.  As long as "something" exists at  
> claranet.de. TLD de. cannot create any wildcard affecting  
> xyzzy.claranet.de., www.xyzzy.claranet.de., etc.

However, TLD wildcards prevent ADSP spoof protections that might  
otherwise have encouraged its application.  Coping with this abuse  
necessitates confirmation of SMTP discovery records.

> Yes, that's the case for xyzzy.claranet.de.  So what ?

Unless the MX record are wildcarded, confirming SMTP discovery records  
eliminates the use of wildcards being a problem.  After all, there are  
other reasons to use wildcards unrelated to SMTP.

>> By depending upon NXDOMAIN, ADSP protections just not possible when  
> ADSP and DKIM are not designed for wildcard tricks, we know this,  
> this has nothing to do with NXDOMAIN, it is just a consequence of  
> using _adsp._domainkey "property-subdomain-labels" (correct term  
> TBD, compare Dave's draft).

Of course, the ADSP policy itself can not be wildcarded due to the  
prefix, but this issue was not the concern.

>> It is ludicrous to suggest domains publish bogus MX records to  
>> avoid undesired SMTP traffic, but those implementing SMTP can not  
>> be expected to publish valid MX records.  This is shameful.
>
> I don't disagree.  But obviously the PTB prefer to handle it  
> elsewhere, in separate RFCs.

Turing in the wrong direction does not properly direct a slow moving  
process.  The harm likely to result could be substantial.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 19 Apr 2008 19:36:02 +0100

> addresses suitable for SMTP and DNS.

DNS yes, but why SMTP? SMTP is not the problem. It is DNS that is  
(possibly) a problem. DKIM already relies on DNS, so I see no reason why  
ADSP should differ.

It would be utterly stupid if someone invented a naming space with the  
same syntax as domain names but using something other than DNS, and then  
let those names wander around freely on the internet. At the very least,  
any such scheme MUST use some TLD(s) distinct from any that is approved  
for DNS usage by ICANN.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Apr 2008 10:45:53 -0700

On Apr 19, 2008, at 11:36 AM, Charles Lindsey wrote:

>> A proprietary scheme is not recommended, but it is not be  
>> unthinkable open source schemes might offer similar features, and  
>> perhaps overcome some of DNS's security issues as well.  Discussing  
>> naming service agility in the abstract is difficult.  However, it  
>> is rather clear ADSP has stipulated DNS and its heuristics.  ADSP  
>> should declare theextent of the policy and stipulate this policy  
>> _only_ relates to email-addresses suitable for SMTP and DNS.
>
> (possibly) a problem. DKIM already relies on DNS, so I see no reason  
> why ADSP should differ.

The current ADSP algorithm establishes DKIM signing compliance by  
qualifying From header email-address domains.  This qualification  
process ensures NXDOMAIN are not returned in response some DNS  
transaction at the domain.

A) With a negative result, an NXDOMAIN response MUST return an error  
(likely resulting in the rejection of the message).

B) With a positive result, not finding an NXDOMAIN implies a valid  
domain without policy when policy records are not found below this or  
the parent's domain at "_adsp._domainkey."

Item A and B are about qualifying the From email-address domain  
signing compliance.  Although DNS is being used for DKIM and ADSP,  
without knowing the protocol used to exchange messages using RFC2822  
 From header email-addresses, it could prove incorrect to assume DNS  
will always publish resource records for all email-address domains.   
Names might be placed in specific TLDs to signal the use of resolving  
services other than DNS.  A strategy adopting specific TLDs that  
ensure non-overlapping name space still runs afoul of ADSP's negative  
existence check based upon its assumption that _all_ domains are found  
in DNS.

Item B fails to properly qualify the From email-address domain  
whenever wildcards are used by some entity related to the domain or  
network service.  Wildcards are used for purposes other than SMTP.

The overwhelming majority of messages carried by SMTP both abuse  
recipients and those spoofed as message sources.  In general, DKIM is  
not the only SMTP extension adding a separate policy.  Both DKIM and  
ADSP must consider the amount of undesired traffic the schemes will  
direct to otherwise innocent third-party victims.  The issues with  
item A and B are mitigated by _positively_ confirming existence of the  
domain's _service_ before assuming policy might exist.  For ADSP, a  
positive check is made by verifying SMTP discovery resource records.   
Placing a requirement that MX records are always published in  
conjunction with ADSP records thereby allows absence of a likely  
cached MX record to terminate any further policy related  
transactions.  This provision offers valuable protection from this  
scheme increasing the level of undesired traffic seen by innocent  
victims of SMTP related abuse.

> It would be utterly stupid if someone invented a naming space with  
> the same syntax as domain names but using something other than DNS,  
> and then let those names wander around freely on the internet. At  
> the very least, any such scheme MUST use some TLD(s) distinct from  
> any that is approved for DNS usage by ICANN.

How does ADSP recognize distinctly different TLDs and unknown  
protocols?  Why not extend this logic to SMTP as well?  Such as:

ADSP compliance requires RFC2822 From email-addresses be deliverable  
using SMTP (which also uses DNS).  Checks for ADSP compliance fail  
when SMTP delivery can not be assured.  ADSP SMTP/DNS compliance  
failures MUST be handled in accordance local policies.

It seems rather bizarre to qualify email-address domain's signing  
policies by ignoring the protocol expected to accept the signed From  
email-address.  What harm is there in stating ADSP compliance is based  
upon SMTP deliverability?

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 22 Apr 2008 10:42:19 +0100

> (likely resulting in the rejection of the message).

But I thought we had already agreed that MUST was a mistake, and needs to
be relaxed (since it is outwith our remit). For sure there is no consensus
to retain it.
> the parent's domain at "_adsp._domainkey."

That's OK. Once you have established that the domain exists in the DNS,
then you are free to look for an associated ADSP policy.

But all that is true regardless of whether the transport is SMTP or
something else.

> not the only SMTP extension adding a separate policy.

DKIM is NOT an "SMTP extension". It is an RFC2822 extension, and arguably
a DNS extension.

> protocols?  Why not extend this logic to SMTP as well?  Such as:

If some TLDs are known not to be accessible via the DNS (which case does
not arise today), then that is a future problem which the nternet will
ahve to worry about. It is way above the level that this WG should be
worried about. It may well turn out to be a matter verifiers will need to
consider when faced with a From header containing an NXDOMAIN, but as I
said above that case is outwith our remit too (though it might merit a
non-normative mention, just to show that its omission was not an accident).

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Apr 2008 11:09:26 -0700

On Apr 22, 2008, at 2:42 AM, Charles Lindsey wrote:

> On Mon, 21 Apr 2008, Douglas Otis <[email-masked]> wrote:
>>
>> A) With a negative result, an NXDOMAIN response MUST return an  
>> error (likely resulting in the rejection of the message).
>
> But I thought we had already agreed that MUST was a mistake, and  
> needs to be relaxed (since it is outwith our remit). For sure there  
> is no consensus to retain it.

Using MUST or SHOULD is not significant, since protection would not be  
obtained when a From email-address domain is not SMTP deliverable, and  
not just whether a domain exists within DNS.

>> domain without policy when policy records are not found below this  
>> or the parent's domain at "_adsp._domainkey."
>
> That's OK. Once you have established that the domain exists in the  
> DNS, then you are free to look for an associated ADSP policy.

Synthesized records might exist, but these records might not be  
indicative of intent to publicly send or receive ADSP covered messages.

> But all that is true regardless of whether the transport is SMTP or  

SMTP defines specific records that MUST exist for SMTP service  
discovery.  Not all records implies a service that _might_ be covered  
by ADSP.  In addition, it is absurd to suggest ADSP ALL policy covers  
_any_ transport.   It would be reasonable to expect SMTP exchanged  
messages are covered by an ADSP ALL assertion.  It is _extremely_  
important to define the scope of the ADSP ALL policy, or this might  
disrupt other public exchange protocols not currently employing DKIM!

>> recipients and those spoofed as message sources.  In general, DKIM  
>> is not the only SMTP extension adding a separate policy.
>
> DKIM is NOT an "SMTP extension". It is an RFC2822 extension, and  
> arguably a DNS extension.

DKIM may used in conjunction with SMTP.  Like it or not, ADSP _is_ an  
SMTP extension.  Otherwise, ADSP MUST list _all_ public exchange  
protocols that MUST incorporate DKIM before asserting an ADSP ALL  
policy.

> If some TLDs are known not to be accessible via the DNS (which case  
> does not arise today), then that is a future problem which the  
> Internet will have to worry about.

Domains used in the From email-addresses may involve local name  
resolution, for example.  This is not only an issue for the future.

> It is way above the level that this WG should be worried about. It  
> may well turn out to be a matter verifiers will need to consider  
> when faced with a From header containing an NXDOMAIN, but as I said  
> above that case is outwith our remit too (though it might merit a  

Determining whether the From email-address is SMTP deliverable offers  
much greater security.  In addition, a convention to terminate policy  
searches when MX records are absent offers SMTP receivers and spoofed  
domains greater protection from undesired traffic.  These significant  
benefits are lost by suggesting ADSP is independent of SMTP.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Apr 2008 09:38:55 -0700

> a confusion and frustration.

That's the fourth result in section 3.2 of ssp-03, "The domain does not 
exist".  So we already have it.  Perhaps it's not clear enough that the 
"appropriate error" referred to in step 2 of section 4.2.2 is that 
particular result.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Apr 2008 09:45:10 -0700

> OK, please provide a list of such domains and we can special-case them.

Any domain with a lot of A records qualifies because you can't tell 
whether they're using the subdomain "for mail" or not.  And we have 
previously decided that trying to publish an assertion whether a domain 
is used for mail or not is out of scope for the WG, so the best we can 
do is to say something about the signing practices.

-Jim

---

From: John Levine <[email-masked]>
Date: Thu, 24 Apr 2008 14:23:36 -0400 (EDT)

> Any domain with a lot of A records qualifies because you can't tell whether 
> they're using the subdomain "for mail" or not.

Just so I'm sure I understand you, you're claiming that DNS managers are 
without exception so hostile and/or incompetent that they can not set up 
ADSP records for the A records they manage.  That's not "would prefer not 
to", it's "can not".  As JD pointed out a few weeks ago, anyone using DKIM 
is going to need to manage new DNS records anyway, so if your DNS managers 
refuse to install anything, you're screwed no matter what ADSP says.

If you're saying this is the situation where you work, I belive you, but I 
know it's not the case everywhere, and one set of uncooperative DNS 
managers seems like a poor basis for casting a permanent DNS kludge in 
stone.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Apr 2008 14:06:25 -0700

On Apr 24, 2008, at 11:23 AM, John Levine wrote:

>>> subdomains for mail that it's impractical to cover the ones they  
>>> use individually?  (Not counting wildcards, we know that's a  
>>> swamp.)  For the domains I know, the mail comes from one or a  
>>> handful of fixed subdomains, and any random subdomain is bogus.
>>>
>> whether they're using the subdomain "for mail" or not.
>
> Just so I'm sure I understand you, you're claiming that DNS managers  
> are without exception so hostile and/or incompetent that they can  
> not set up ADSP records for the A records they manage.  That's not  
> "would prefer not to", it's "can not".  As JD pointed out a few  
> weeks ago, anyone using DKIM is going to need to manage new DNS  
> records anyway, so if your DNS managers refuse to install anything,  
> you're screwed no matter what ADSP says.
>
> If you're saying this is the situation where you work, I belive you,  
> but I know it's not the case everywhere, and one set of  
> uncooperative DNS managers seems like a poor basis for casting a  
> permanent DNS kludge in
> stone.

Agreed.  Positive confirmation of specific record use (A or MX in  
conjunction with ADSP records) also avoids issues related to wildcards  
for records other than A or MX.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Apr 2008 09:22:53 +0200

John,
> ADSP records for the A records they manage.
>   

I don't think that's what Jim was saying, but I'm sure he can answer for 
himself.

What I would say is that there are several situations that must be 
considered.  In some instances, it has absolutely nothing to do with 
level of expertise of the administrator but the tools that he or she is 
using, that will need to be changed.  Without exception administrators 
that rely on the expertise of the tool will need to wait for that tool 
to have that expertise.  Other administrators will likely have to modify 
templates to roll out.

Here's the question I wonder about here: how do we follow as best we can 
the principle of least astonishment in this case?

Eliot

---

From: John Levine <[email-masked]>
Date: Fri, 25 Apr 2008 11:46:41 -0400 (EDT)

> considered.  In some instances, it has absolutely nothing to do with level of 
> expertise of the administrator but the tools that he or she is using, that 
> will need to be changed.

Indeed.  But the tools are going to have to change to handle DKIM, so I 
don't see any advantage to hacks whose only advantage is that they let you 
skip one of N changes to the toolset.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Apr 2008 10:33:01 -0700

On Apr 25, 2008, at 12:22 AM, Eliot Lear wrote:

> Here's the question I wonder about here: how do we follow as best we  
> can the principle of least astonishment in this case?

Bad-actors run an overwhelming majority of SMTP clients.  Each SMTP  
set-up expediency, even under a guise of least astonishment, creates  
additional burdens on the Internet.  Not only should each domain  
seeking SMTP policy protections publish records at each SMTP domain,  
each SMTP domain should also publish MX records in conjunction with  
the SMTP policy.  When an MX record is not published, uninvolved  
domains can then be assured recipients of spoofed SMTP messages will  
stop at not finding MX records and not climbing up their domain tree  
looking for what might become a plethora of various message policies.

After all, the _only_ public message exchange protocol to benefit from  
ADSP policy is SMTP.  Denials that ADSP is not tightly bound to SMTP  
are astonishing.  While other public message exchange protocols  
_might_ incorporate DKIM, _each_ and _every_  public exchange protocol  
requires _separate_ policy assertions to signal when DKIM becomes  
fully incorporated.  Separate policies for each public exchange  
protocol offers the least astonishment and avoids significant  
disruptions that can be caused by the ambiguous application of  
policy.  Publishing policy at each domain holding evidence of  
supporting a corresponding public message exchange protocol is not  
astonishing.  Once such a concept is embraced, policy only needs to  
occur in conjunction with the service discovery records.  Of course,  
expecting negative domain existence to always provide a valid result  
would also be astonishing.

ADSP is intended to offer a few phished domains added protections.   
Rather than requiring additional steps for each message that crosses  
over the transom, require those seeking added protections to carry the  
additional burden of publishing policy where protection is being  
sought.  Domain reputation can only be enforced within the forward DNS  
zone.  Limited PTR sets in the reverse zone requires forward/reverse  
name mismatch be overlooked.  A practical means to confirm that a  
domain supports the SMTP service is the MX record.  MX records should  
become the touch-stone for domain reputations and policies.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Apr 2008 19:37:35 +0200

Doug,

I'm a simple guy.  I only have a few brain cells left at this point.  A 
little too much LDS in the '70s.  Please.  Smaller simpler sentences to 
address my question, which was:

>> can the principle of least astonishment in this case?

In other words, what is it administrators can/should reasonably expect 
as a behavior/requirement?  What are examples of things that are likely 
to astonish them in this case?

Eliot

---

From: John Levine <[email-masked]>
Date: Fri, 25 Apr 2008 19:42:02 -0400 (EDT)

>  DNS administrators ...
> But they are, as far as this protocol is concerned, our customers.

No, they're not.  They one of many suppliers to our customers.  Our 
customers are people who send and recieve mail.

> The requirement to publish large numbers of ADSP records is a barrier to its 
> widespread adoption, at least its adoption in a way that provides broad 
> coverage for domains.  This can be addressed with tools, but the requirement 
> to add tooling to achieve good ADSP coverage is also a deployment barrier.

Perhaps, although as I've said, reducing the work for DNS toolsmniths from 
N changes to N-1 changes doesn't strike me as as a very good rationale for 
a long term gross hack.  If the history of SPF is any guide, should we 
ship ADSP with this hack, people will start claiming that all domains must 
change their naming conventions so they're only two levels deep.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Apr 2008 16:21:50 -0700

John Levine wrote:
> are without exception so hostile and/or incompetent that they can not 
> set up ADSP records for the A records they manage.  That's not "would 
> prefer not to", it's "can not".  As JD pointed out a few weeks ago, 
> anyone using DKIM is going to need to manage new DNS records anyway, 
> so if your DNS managers refuse to install anything, you're screwed no 
> matter what ADSP says.

It isn't productive to dismiss DNS administrators who are resistant to 
adding many ADSP records as "lazy", "hostile", and/or "incompetent".  It 
makes it sound like they aren't worthy of using ADSP.  But they are, as 
far as this protocol is concerned, our customers.

The requirement to publish large numbers of ADSP records is a barrier to 
its widespread adoption, at least its adoption in a way that provides 
broad coverage for domains.  This can be addressed with tools, but the 
requirement to add tooling to achieve good ADSP coverage is also a 
deployment barrier.  Similar concerns led the WG to the use of TXT 
records rather than a new RR.  There are a lot of DNS management tools 
out there that would need to change in order to publish the necessary 
ADSP records, and this would take considerable time.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Apr 2008 17:29:56 -0700

On Apr 25, 2008, at 4:21 PM, Jim Fenton wrote:

> The requirement to publish large numbers of ADSP records is a  
> barrier to its widespread adoption, at least its adoption in a way  
> that provides broad coverage for domains.  This can be addressed  
> with tools, but the requirement to add tooling to achieve good ADSP  
> coverage is also a deployment barrier.  Similar concerns led the WG  
> to the use of TXT records rather than a new RR.  There are a lot of  
> DNS management tools out there that would need to change in order to  
> publish the necessary ADSP records, and this would take considerable  
> time.

Publishing ADSP records in conjunction with SMTP discovery records  
should not be described as "large" numbers.  This would have a direct  
correspondence with records already published.  Lack of NXDOMAIN as  
component of ADSP validation is wholly unmanageable and can easily  
explode into large number.

Why not depend upon discovery records?  How many public message  
exchange protocols beyond SMTP will use ADSP records?  Who even  
expects widespread adoption of ADSP?  Why would it be difficult to  
provide ADSP coverage predicated upon the existence of SMTP discovery  
records?  The lack of MX records should also preclude the use of ADSP.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Apr 2008 18:54:36 -0700

Jim,

> far as this protocol is concerned, our customers.

Whatever one thinks of the tone used to express the issue, the objective fact 
is that the two-level mechanism specified in the current draft is attempting 
to define a new, two-level semantic on the DNS.  As such, it is a paradigm change.

One should make paradigm changes to long-standing infrastructure services only 
when there is clear and substantial benefit and very, very broad support for it.

I keep waiting for proponents of this 'feature' to solicit technical review 
from independent DNS and security experts, for assessing the likely benefit as 
balanced against the likely cost.

> its widespread adoption

That's a view I do not recall seeing phrased quite that way before.  It's 
nicely succinct and pragmatic.  The only question is where is its basis and, 
again, the broad support for the assessment that substantiates it?

For example, John has provided some counter-arguments suggesting that the 
actual, incremental effort to deal with a large number of parallel, related 
domains -- for this particular RR -- is not all that high, particularly in 
light of the core requirement for change to tools, needed to support even only 
one name and record.  In addition, I haven't seen an analysis that explains 
who all these affected domain name owners are likely to be.  In other words, 
to be a serious barrier to adoption, it must be a serious barrier and it must 
affect a significant portion of potential adopters.  Where is the analysis 
that demonstrates this?  Where is the groundswell of their calling for this 
feature?

> deployment barrier.  

As John noted, there is already a requirement for modifying tools, in order to 
support ADSP.

> Similar concerns led the WG to the use of TXT 
> records rather than a new RR.

Not really. The infrastructure barrier to support of a new RR exists with both 
those who create the record as well as those access it.

The barrier for ADSP is only with those who create the record.  Very, very 
different dynamic.

>     There are a lot of DNS management tools 

They already need to change, to support one record (for one domain.)  How is 
there something fundamentally worse about having to support many?

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Sun, 27 Apr 2008 21:46:22 -0700

Douglas Otis wrote:
>> The requirement to publish large numbers of ADSP records is a barrier 
>> to its widespread adoption, at least its adoption in a way that 
>> provides broad coverage for domains.  This can be addressed with 
>> tools, but the requirement to add tooling to achieve good ADSP 

We're not really talking about the use of NXDOMAIN in this part of the 
thread, although I'm not surprised if you're confused because we have 
(again) forgotten to change the subject line when we have changed topics.

> records?  The lack of MX records should also preclude the use of ADSP.

Discovery records for SMTP are both MX and A, and that isn't changing.  
My point is that there are far too many A records in many domains for it 
to be practical to publish an ADSP record to go with each one, lacking 
tools to do so.  And a requirement to deploy new DNS tools will hinder 
coverage greatly.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sun, 27 Apr 2008 21:53:35 -0700

Dave Crocker wrote:
> I keep waiting for proponents of this 'feature' to solicit technical 
> review from independent DNS and security experts, for assessing the 
> likely benefit as balanced against the likely cost.

I have been soliciting technical review from the DNS folks, literally, 
for years, on this and prior iterations. I recall quite clearly a 
lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over 
two years ago. I have been less concerned with independent security 
review, since we are in that area and I expect that will happen with the 
specification as a whole, not just this aspect of it.

>> to its widespread adoption
>
> That's a view I do not recall seeing phrased quite that way before.  
> It's nicely succinct and pragmatic.  The only question is where is its 
> basis and, again, the broad support for the assessment that 
> substantiates it?
>
> For example, John has provided some counter-arguments suggesting that 
> the actual, incremental effort to deal with a large number of 
> parallel, related domains -- for this particular RR -- is not all that 
> high, particularly in light of the core requirement for change to 
> tools, needed to support even only one name and record.  In addition, 
> I haven't seen an analysis that explains who all these affected domain 
> name owners are likely to be.  In other words, to be a serious barrier 
> to adoption, it must be a serious barrier and it must affect a 
> significant portion of potential adopters.  Where is the analysis that 
> demonstrates this?  Where is the groundswell of their calling for this 
> feature?

I don't see an analysis for John's assertion either.

>> broad coverage for domains.  This can be addressed with tools, but 
>> the requirement to add tooling to achieve good ADSP coverage is also 
>> a deployment barrier.  
>
> As John noted, there is already a requirement for modifying tools, in 
> order to support ADSP.

Not DNS tools. The requirement to modify DNS tools to achieve broad 
coverage would be an additional requirement.

>> Similar concerns led the WG to the use of TXT records rather than a 
>> new RR.
>
> Not really. The infrastructure barrier to support of a new RR exists 
> with both those who create the record as well as those access it.
>
> The barrier for ADSP is only with those who create the record.  Very, 
> very different dynamic.

Agree that ADSP requires changes only on the publication side. I still 
believe that this introduces a significant barrier.

>>     There are a lot of DNS management tools out there that would need 
>> to change in order to publish the necessary ADSP records, and this 
>> would take considerable time.
>
> They already need to change, to support one record (for one domain.)  
> How is there something fundamentally worse about having to support many?

The tools don't need to change; the additional TXT record for ADSP can 
just be published independently using existing tools.

We have two approaches to this problem, one approach which requires more 
effort on the part of ADSP publishers (either manual publication of 
additional records or deployment of new DNS tools), and one approach 
that requires more effort on the part of ADSP users, although that 
effort is largely contained within the software implementing ADSP and 
transparent to the deployer. Let's just treat this as an engineering 
tradeoff.

I'm rather surprised this has become such an issue for you and John 
since this same approach is used in draft-levine-asp-00, which John 
edited and on which you collaborated.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Apr 2008 01:58:49 -0700

On Apr 27, 2008, at 9:46 PM, Jim Fenton wrote:
>> provide ADSP coverage predicated upon the existence of SMTP  
>> discovery records?  The lack of MX records should also preclude the  
>> use of ADSP.
>
> Discovery records for SMTP are both MX and A, and that isn't  
> changing.  My point is that there are far too many A records in many  
> domains for it to be practical to publish an ADSP record to go with  
> each one, lacking tools to do so.

Domains benefiting enough to publish ADSP ALL policy at every node are  
likely to remain in the minority.  A publishing convenience that  
depends upon receivers walking up two domain levels adds unnecessary  
DNS transactions for all emails, and exposes second level domains to  
undesired transactions that are beyond their control.  Higher  
processing overhead occurs for each email, where the majority are  
undesired.  Minimizing associated overhead in the face of massive  
undesired messaging is the _only_ means that might help ensure broader  
ADSP receiver adoption.

Until deprecated for SMTP public interchange discovery, the only  
practical solution would be to include ADSP records at every node  
containing A records.  When publishing A records is possible, so is  
publishing ADSP records.  ADSP's use of large text labels should be re- 
examined with respect to an unnecessary impact on zone sizes.  DNS is  
not intended for human consumption.

> And a requirement to deploy new DNS tools will hinder coverage  
> greatly.

Rather than tools, better definitions are needed for the name space  
used with SMTP and ADSP.  Public SMTP interchange should be able to  
impose possible MX requirements as a local policy option during  
reception.  In addition, the lack of MX should also preclude ADSP  
related transactions.  SMTP must remain functional for deployments  
where DNS is not used, not related to public exchanges.  Such  
functional differentiation seems well suited to the application of  
local policy.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 28 Apr 2008 11:13:25 +0100

On Sat, 26 Apr 2008 02:54:36 +0100, Dave Crocker <[email-masked]> wrote:

> How is
A competent admin sets up his domains correctly, with ADSP records  
corresponding to every A/MX record that should have one.

Then he goes on holiday, or leaves, or whatever, and his junior assistant  
is told by his Boss "I want this machine added to our network, and I want  
it adding NOW". So he creates an A record and leaves it at that.

This is the Real World and that is the way things happen, whether we like  
it or not.

At least the two-level process described in the current draft (which is  
indeed a compromise and a hack) will protect against a very large fraction  
of such "accidents".

---

From: "Al Iverson" <[email-masked]>
Date: Mon, 28 Apr 2008 10:50:18 -0400

>  edited and on which you collaborated.

I don't grasp the technical bits to provide a coherent explanation of
how to do what I want. But I have to say, without any sort of domain
blanket/coverage option, it seems like something is really missing
here. Without any sort of assumption or ability to limit what's
allowed under spamresource.com, I think ADSP is much less useful. My
concern is that if I can't restrict or cause failures automatically
outside of a specific subdomain or host, it does me little good to
sign on signed.spamresource.com when a phisher can fake
signed2.spamresource.com and not automatically be failed by checking
sites.

If I'm understanding the issues at hand. The thread is a bit difficult
to follow. I gather from some friendly offlist explanation that Jim
advocates a domain-wide signing policy that would go 1-2 sublevels
deep and no deeper. Jim, is that basically correct? I'd love an
example or two of how this works with 1-2 level deep signed and
spoofed fqdns, and what happens with levels deeper (no opportunity for
DKIM? or ADSP?)

Best,
Al

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Apr 2008 08:18:36 -0700

Al,

Al Iverson wrote:
>     My

I believe there is no disagreement about whether the capability would be nice. 
  This is all about the technical feasibility, given real-world DNS constraints.

So let's take your underlying assumption:  What, exactly, is the scenario that 
uses a faked domain name and is effective?

We are probably going to find different assumptions about how things are 
processed.

What do you believe happens after they slip past this ADSP filter, that makes 
this fake use damaging?

d/
-- 

   Dave Crocker

---

From: "J D Falk" <[email-masked]>
Date: Mon, 28 Apr 2008 12:02:38 -0400

Al wrote:

> Without any sort of assumption or ability to limit what's allowed
under
> spamresource.com, I think ADSP is much less useful. My concern is that
> if I can't restrict or cause failures automatically outside of a
> specific subdomain or host, it does me little good to sign on
> signed.spamresource.com when a phisher can fake
signed2.spamresource.com
> and not automatically be failed by checking sites.

It /will/ automatically be failed by DKIM (bad or no signature being
equivalent), and by any modern anti-spam system (because the host or
domain doesn't exist.)  I can't imagine any situation where an MTA
administrator will choose to disable all other checks, and rely solely
on ADSP.

> to follow.

Yeah, I don't think there's much point in following it closely anymore.
The really really smart people appear intractable, and the rest of us
aren't making much sense.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Apr 2008 10:31:33 -0700

On Apr 28, 2008, at 9:02 AM, J D Falk wrote:

>> under spamresource.com, I think ADSP is much less useful. My  
>> signed2.spamresource.com and not automatically be failed by  
>> checking sites.
>
> administrator will choose to disable all other checks, and rely  
> solely on ADSP.

J.D.

Bad actors are still able to spoof (unsigned) messages from  
mx01.sfo.example.com, even when example.com publishes ADSP policy at  
_adsp._domainkey.example.com.  Unless a recipient attempts to make TCP  
connections to port 25, mx01.sfo.example.com will appear as a valid  
source within example.com.  A potential spoofing problem still exists  
against hostnames found within the ADSP protected domain.  A solution  
that avoids doubling the number of DNS transactions for each email  
received requires domains seeking protection to publish ADSP records  
at every hostname.

Adopting an MX requirement for SMTP public exchanges is yet another  
solution that also scales for any number of policies without mandating  
replicate policy records at every hostname.  Public exchanges over  
SMTP should expect the presence of MX records.  However, private  
exchanges should not depend upon DNS.  This remains an interesting  
problem. : )

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Mon, 28 Apr 2008 13:48:29 -0400

>  aren't making much sense.

So, o fellow reasonable man, which way is the path back to
civilization? Do you feel there is is a way ADSP /should/ work here,
and if so, which way and why?

Best,
Al

---

From: Steve Atkins <[email-masked]>
Date: Mon, 28 Apr 2008 11:03:34 -0700

> and if so, which way and why?

The answer to that depends on what the operational goal
of ADSP is. And that's never been clearly stated, really,
certainly not to the level of there being any consensus on it.

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Mon, 28 Apr 2008 11:20:09 -0700

Al Iverson wrote:
> deep and no deeper. Jim, is that basically correct?
You have it right, but it's only one sublevel.  In other words, if you 
publish an ADSP record for example.com, it would apply to any names in 
the immediate subdomain that don't have their own ADSP record (perhaps 
ns.example.com, www.example.com, etc.), but no deeper than that (i.e., 
not foo.eng.example.com).

The application of records to an immediate subdomain can also be turned 
off by the t=s flag in the ADSP record.
> I'd love an

Of course, any domain name, no matter how deep in the hierarchy, can 
sign with DKIM by publishing a key record in one of the appropriate 
places.  So xyz.marketing.example.com could publish a selector at, for 
example, april2008._domainkey.xyz.marketing.example.com, and sign 
messages using d=xyz.marketing.example.com.  A parent domain could also 
sign, for example using a key at brisbane._domainkey.example.com and 
using d=example.com and i=@xyz.marketing.example.com.

For ADSP, let's consider the following domain, example.net:

MX record pointing to mail.example.net and mail2.example.net
NS records pointing to ns.example.net and ns2.example.net
A records for mail, mail2, ns, ns2, www, gateway, and a DHCP pool 
consisting of host1 through host100.
NS records for finance.example.net pointing to ns.example.net and 
ns2.example.net
A records for larry.eng.example.net, curly.eng.example.net, and 
moe.eng.example.net (published as A records in the same zone)
A records for a DHCP pool consisting of host1.finance.example.net 
through host50.finance.example.net (published in a separate zone)
MX records for finance.example.net pointing to mail.example.net and 
mail2.example.net

So, as currently specified in the latest ADSP draft (-ssp-03), an ADSP 
record published at _asp._domainkey.example.net will provide coverage 
for mail sent from the following domains:  example.net, 
mail.example.net, mail2.example.net, ns.example.net, ns2.example.net, 
www.example.net, gateway.example.net, the hosts host1.example.net 
through host100.example.net, and finance.example.net.

It does not provide coverage for the hosts host1.finance.example.net 
through host50.finance.example.net. To get this coverage, one could add 
an ADSP record at _asp._domainkey.finance.example.net.

It also does not provide coverage for the hosts larry.eng.example.net, 
curly.eng.example.net, and moe.eng.example.net.  To get this coverage, 
one could add an ADSP record at _asp._domainkey.eng.example.net.

Of course, one could always publish individual ADSP records for the hosts.

Hope this makes things clearer.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Apr 2008 12:30:56 +0200

Steve,
> certainly not to the level of there being any consensus on it.

Really?  How about Section 1 of RFC 5016?

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Tue, 29 Apr 2008 07:47:10 -0700

> Really?  How about Section 1 of RFC 5016?

It doesn't contain any operational justification or goal for
SSP. It describes what (one person) wants from SSP, it
does not explain why, and it definitely doesn't provide the
operational problem that SSP is intended to mitigate.

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Apr 2008 17:36:02 +0200

> operational problem that SSP is intended to mitigate.

Well, I really don't know where to begin.  Here's the text.

>    DomainKeys Identified Mail [RFC4871] defines a message level signing
>    and verification mechanism for email.  While a DKIM signed message
>    speaks for itself, there is ambiguity if a message doesn't have a
>    valid first party signature (i.e., on behalf of the [RFC2822].From
>    address): is this to be expected or not?  For email, this is an
>    especially difficult problem since there is no expectation of a
>    priori knowledge of a sending domain's practices.  This ambiguity can
>    be used to mount a bid down attack that is inherent with systems like
>    email that allow optional authentication: if a receiver doesn't know
>    otherwise, it should not assume that the lack of a valid signature is
>    exceptional without other information.  Thus, an attacker can take
>    advantage of the ambiguity and simply not sign messages.  If a
>    protocol could be developed for a domain to publish its DKIM signing
>    practices, a message verifier could take that into account when it
>    receives an unsigned piece of email.

Put another way, you can't tell the difference between "doesn't use 
DKIM" with "this is a forged message" without either SSP or some 
out-of-band (and unmentioned) mechanism.  If you're asking for more 
specifics about what YOU should do with a message once it's determined 
to (a) not have a valid signature and (b) have a policy of signing all 
messages, I'm afraid that Dave and others have befuddled this group into 
thinking that's a bad idea and somehow out of scope.

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Tue, 29 Apr 2008 08:38:56 -0700

On Apr 29, 2008, at 8:36 AM, Eliot Lear wrote:

> DKIM" with "this is a forged message" without either SSP or some out- 
> of-band (and unmentioned) mechanism.  If you're asking for more  
> specifics about what YOU should do with a message once it's  
> determined to (a) not have a valid signature and (b) have a policy  
> of signing all messages, I'm afraid that Dave and others have  
> befuddled this group into thinking that's a bad idea and somehow out  
> of scope.

And what's the actual operational goal for this?

If you can't give me the general goal, a concrete example or
two would be a good start.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2008 09:28:43 -0700

> lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over 

Excellent.  So it will not be difficult to document that formal review so that 
the rest of us can consider its careful documentation of the DNS community's 
assessment of the peculiar mechanisms defined in the working group draft.

The point behind my probe for formal review was just that:  formal review. 
Casual, private conversations might be a precursor, but they are not 
sufficient, particularly when seeking to modify the DNS's exact-match paradigm 
for queries.

> specification as a whole, not just this aspect of it.

Jim, waiting until we are done, to get buy-in from the rest of the security 
community is singularly ill-advised project management.  It maximizes risk and 
minimizes benefit, particularly when there is very basic concern over the 
efficacy of what is being proposed.

I realize that you are not the one with the concern, but you might have 
noticed that there are others in the working group who do not share your comfort?

...
> I don't see an analysis for John's assertion either.

When seeking to add something to a specification, the burden of establishing 
that it is necessary or, at least, beneficial, falls on those who are 
proponents.  Additions create costs. In the case of Internet standards, the 
costs are large-scale and long-term.  The costs need to be justified.

Let me anticipate a counter-argument that might be put forward:  The feature 
in question is already in the specification so the challenge is in 
establishing that it must be removed.  The problem with this view is that 
there was never a clear consensus to add it.  Really.  I've asked for 
documentation to the contrary and it has not been forthcoming.

> coverage would be an additional requirement.

I don't understand your response.

> believe that this introduces a significant barrier.

Having to make any changes to DNS administration is a barrier.  Right.

And your point is what, exactly?

The current point was not whether there was any barrier at all, but rather it 
was about your attempt to equate the height of the barrier for a new RR with 
that of a new use for an existing one (TXT).  My response was that they are 
massively different barriers.

> just be published independently using existing tools.

Jim, some DNS admin tools do not automatically permit that.  They need to be 
changed.

> transparent to the deployer. Let's just treat this as an engineering 

Yes, let's.  But let's do that in a discussion with substance, rather than a 
wave of the hand, which is frankly what I think the above paragraph represents.

An engineering tradeoff decision needs an engineering costs/benefits discussion.

For the current case, the choice is between a possible burden on what is 
probably a small number of administrators, versus a very real real-time 
overhead burden on virtually every email exchange over the open Internet... 
forever.  Worse, the burden is not likely to have accompanying benefits.

> edited and on which you collaborated.

Here, you move into a kind of process challenge, and even toss in some ad 
hominem.  Citing only John and me also nicely seeks to marginalize the concerns.

More importantly, you seem to have missed or forgotten a number of my own 
postings that explain what is motivating the concerns.

So let's review some history about *technical* and *operational* concerns:

On 11 April, Dave Crocker wrote (to you privately):
 > Have you considered the relative costs (and benefits)?
 >
 > who has to publish the extra records?  for how many of these will that
 > be onerous?
 >
 > who will do the extra queries? for how many queries will the extra
 > overhead be useful?

Did these not seem sufficiently basic or legitimate questions?  They ought to 
explain my own reason for pressing concerns about these extra DNS details.

How about my 9 April posting to the list:
> Dave Crocker wrote:
>> Given that the DNS is not designed to permit this conveniently and, in 
>> fact, does not seem to me to be able to do it at all, we certainly need 
>> a complete and coherent technical description of how ADSP accomplishes 
>> complete coverage of a sub-tree.
>> 
>> This would describe the approach being taken for covering a sub-tree, 
>> and the component mechanisms being used to achieve it -- Step 2 is but 
>> one of those components. It would also demonstrate what kind of attacks 
>> it protects against.
>> 
>> I am not aware of any previous technology providing such sub-tree 
>> functionality, and so this ought to be subject to careful review by the 
>> DNS and Security folks.  At that, I fear it will nonetheless warrant a 
>> status of "experimental".
>> 
>> So in terms of a "goal" I'm probably in agreement that it would be dandy 
>> to do.   But I think that my desiring that goal is pretty much irrelevant.
>> 
>> The problem is that I believe there is no technical means of covering a 
>> subtree completely, except by case-analysis, which isn't covering a tree 
>> at all.
>> 
>> I believe the Step 2 query only makes sense for ADSP in the context of 
>> covering an entire sub-tree, but that ADSP does not describe the larger 
>> framework into which Step 2 fits, for accomplishing that goal.

How about 2 March:
Dave Crocker wrote:
 > Put forward as an efficiency hack, to avoid having to make a number of
 > one-level-down DNS records, the mechanism has no claim towards affecting
 > security.  Taken on its own, therefore, the question is whether the
 > mechanism as a) worth the effort on a normal implementation cost vs.
 > operational benefit basis, and b) worth the effort to run contrary to
 > established DNS practice and, now, IAB preferences.
 >
 > Put forward as having any security characteristics, such as enforcing
 > the ASP security model, this DNS hack is likely to have quite a bit of
 > pushback, as you note.

I seem to recall other, earlier and similar postings, but these ought to 
suffice, both to explain why the matter is being pressed and that pressing the 
matter is being spontaneously generated.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Apr 2008 18:09:50 +0200

> two would be a good start.

The general goal is to discern that which isn't signed and should be 
signed and that which legitimately not be signed.  I think one can 
easily derive an operational goal from that but that's where last 
December's war happened.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2008 09:57:49 -0700

Eliot Lear wrote:
> 
>       and that which legitimately not be signed.  

huh?

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Apr 2008 15:58:26 +0100

Hi Dave,

> sufficient, particularly when seeking to modify the DNS's exact-match paradigm 

I'm not entirely sure what'd constitute such a formal review. If
you've input there that'd be useful. (As Jim says, we have asked
members of the DNS directorate publicly, and a number of times.)

However, I guess what we can do is send the draft to the DNS
directorate at the close of WGLC. Would that be ok?

S.