Subject: [ietf-dkim] SSP draft suggestions

From: Arvel Hathcock <[email-masked]>
Date: Mon, 23 Jul 2007 14:52:46 -0500

Just a few small suggestions:

1)  In several places the language "SHOULD be considered non-Suspicious" 
is used.  This seems an awkward way to say it.  Since the term 
"Suspicious" is defined in section 2.8 "SHOULD NOT be considered 
Suspicious" might be a better way?  Also "MUST be considered 
non-Suspicious" -> "MUST NOT be considered Suspicious"?

2)  Section 3 bullet point 3 - "and SHOULD have a Valid Signature from 
this domain" -> "and SHOULD have a valid Originator Signature"

3) "not to be legitimate" -> "to be illegitimate"

4) ", and any verifiable signature is present from some signer other 
than the Originator Address in the message" -> "and the message contains 
a Verifier Acceptable Third-Party Signature"

5) "SHOULD NOT be considered to be Suspicious" -> "SHOULD NOT be 
considered Suspicious"

6) Section 4.1 - perhaps this is a better way of stating the second 
sentence in the NON-NORMATIVE DISCUSSION paragraph:

 "Many DNS server and resolver implementations are incapable of quickly 
and easily supporting new resource record types.  For this reason, 
support of TXT records is required whether a new RR type is defined or 
not."

7)  Section 4.1 states that syntactically incorrect SSP records should 
be considered as NODATA.  This is different from the 4871 approach of 
simply ignoring unknown tag/value combinations.  This also precludes the 
ability to extend an existing SSP record with some future new tag 
(should that need ever arise).  Was this intended?  It seems to 
contradict what's stated later in 4.3 that unknown tags are to be ignored.

8)  "whcih" -> "which"

9)  "Originating Domain" is used as if it was one of the previously 
defined terms but it isn't.

10)  "and its all of its" -> "and all of its"

11)  Personally, I like the suggestion someone else made of changing 
"unknown" to "?" but this isn't particularly important really.

12)  Section 4.4 - "including any where the Alleged Signer is" -> did 
you mean "including anywhere the Alleged Signer or"

13) Algorithm 2 - "to the domain part of the Originator Address" - it 
seems like you'd want to define "Originator Domain" in the definitions 
section and use that in a few places.

14) Algorithm 2 - "with one or more answer which is a 
syntactically-valid SSP response" -> "with one or more syntactically 
valid SSP responses"

15) Algorithm 3 has me a little worried.  It would prevent the use of 
domains unless they explicitly exist in DNS.  So, if I wanted to send a 
message out from [email-masked] I would have to make sure and 
create a DNS A record or something for sms.altn.com first right?  
(sorry, my knowledge of DNS is not so good)

16) Algorithm 4 - "of the domain part of the domain part" -> "of the 
domain part"  this is another case where defining Originator Domain in 
advance might be helpful.

17) Algorithm 4 - "is a top-level domain" how can that be determined in 
practice?  I don't think it can can it? If not, we're giving algorithmic 
instruction here that is impossible to implement.

18) Algorithm 5 - unless we can figure out how to stop queries at 
top-level domains, Algorithm 5 will send lots of queries to the root 
servers right (.co.uk for example)?

19) Algorithm 8 - "and one or more Valid Signatures are present" -> 
Valid Signatures doesn't say enough here.  In this case a valid 
Originator Signature or a valid Verifier Acceptable Third-Party 
Signature" is what you want.

Arvel

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

---

From: Jim Fenton <[email-masked]>
Date: Wed, 25 Jul 2007 19:45:11 -0700

Arvel,

Thank you.  Eric Allman and I went over your suggestions while we were
marking up the SSP draft, and they help a lot.  Most of them we're just
going to incorporate, so I won't comment on those.  Here are our
comments on the rest:

Arvel Hathcock wrote:
> 1)  In several places the language "SHOULD be considered
> non-Suspicious" is used.  This seems an awkward way to say it.  Since
> the term "Suspicious" is defined in section 2.8 "SHOULD NOT be
> considered Suspicious" might be a better way?  Also "MUST be
> considered non-Suspicious" -> "MUST NOT be considered Suspicious"?

We were a little mixed on this.  Agree that non-suspicious is probably
not a word; it should be "not suspicious".  But considering something to
be not suspicious is not quite the same thing as not considering
something to be suspicious.  Even though SSP only produces one of two
results, it seems clearer to say that the answer is "not suspicious"
than to say that the answer isn't "suspicious".  We're doing some
wordsmithing on this, including being more consistent on the use of
SHOULD and MUST.
> 3) "not to be legitimate" -> "to be illegitimate"

The whole use of the word "legitimate" is being removed; it creates
confusion about legitimate vs. not suspicious and so forth.  So this
will be a moot point.
> than the Originator Address in the message" -> "and the message
> contains a Verifier Acceptable Third-Party Signature"

I like your wording, although this part of the text will be removed when
we collapse the text in removing the use of "legitimate".

> simply ignoring unknown tag/value combinations.  This also precludes
> the ability to extend an existing SSP record with some future new tag

What this points out is that there isn't actually a formal definition of
the record syntax.  We need some ABNF for this, and will consider the
need for future new tags.
> "unknown" to "?" but this isn't particularly important really.

Eric and I like "unknown" because it's less cryptic and there isn't any
reason to save a few characters here.  If there's consensus to the
contrary, we'll of course change it.
> you mean "including anywhere the Alleged Signer or"

This sentence will go away.
> section and use that in a few places.

Yes; thanks for pointing out the repetition.
> syntactically-valid SSP response" -> "with one or more syntactically

Right.  This points out that we need to think about what happens if we
get more than one SSP response.  Any opinions?
> domains unless they explicitly exist in DNS.  So, if I wanted to send
> a message out from [email-masked] I would have to make sure and

You should probably have an MX record anyway for sms.altn.com,
especially if that's also the envelope-from address (so it can receive
bounces).  It doesn't need to be an A record; any record type will do.

> 17) Algorithm 4 - "is a top-level domain" how can that be determined
> in practice?  I don't think it can can it? If not, we're giving
> algorithmic instruction here that is impossible to implement.

A top-level domain is one that has exactly one component, e.g., "com",
"org", "uk", or "tv".  We also talk about suffixes, which would probably
include "co.uk", "k12.ca.us", and "edu.au".  We mandate not querying the
top-level domains, since they can be algorithmically determined and we
really don't want to unnecessarily load the TLD servers.  Not querying
suffixes is optional, as the definition for what a "suffix" is, because
there is no formal definition and this is really an optimization.
> servers right (.co.uk for example)?

.co.uk isn't a root server, it's a suffix.  The root servers are the
places you query to find the name servers for ".com", ".us", ".hr", and
so forth.  It may send quite a number of queries to the .co.uk name
servers, which is why you may want to have it in your suffix list, but
even if it's not, the number of queries should be limited by the minimum
TTL of the zone it's in (the negative caching time).

Again, thanks for your comments!

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 26 Jul 2007 11:21:05 -0500

> "org", "uk", or "tv".  We also talk about suffixes, which would
 > probably include "co.uk", "k12.ca.us", and "edu.au".  We mandate not
 > querying the top-level domains, since they can be algorithmically
 > determined and we really don't want to unnecessarily load the TLD
 > servers.

Thanks much for clearing this up for me.  I'm obviously not a DNS 
expert.  Now that I understand better I see I was wrong and it will be 
possible to algorithmically avoid querying the TLDs.

So, my concerns surrounding #4 and #5 were based on a misunderstanding 
on my part which is now cleared up.

Thanks again!

-- 
Arvel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Jul 2007 18:19:59 +0100

> get more than one SSP response.  Any opinions?

Good question. Would simply using the most restrictive be an option?
(Implies a partial order for all SSP statements though, which may
not be true in general.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Jul 2007 18:21:12 +0100

> possible to algorithmically avoid querying the TLDs.

Well, I'm not sure that's entirely true, but it may be good enough,
I'm not sure. (We do have some similar text in base though so adding
that here as well isn't very different.)

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jul 2007 10:44:00 -0700

On Jul 25, 2007, at 7:45 PM, Jim Fenton wrote:

>> syntactically-valid SSP response" -> "with one or more  
>> syntactically valid SSP responses"
>
> Right.  This points out that we need to think about what happens if  
> we get more than one SSP response.  Any opinions?

If SSP is ever defined for more than just TXT records, then multiple  
RRs containing multiple syntactically valid responses would be  
possible.  Assuming that rejection should occur when these records  
differ begs the question, "How will the SSP format evolve?"

>> 15) Algorithm 3 has me a little worried.  It would prevent the use  
>> of domains unless they explicitly exist in DNS.  So, if I wanted  
>> to send a message out from [email-masked] I would have to  
>> make sure and create a DNS A record or something for sms.altn.com  
>> first right?  (sorry, my knowledge of DNS is not so good)
>
> especially if that's also the envelope-from address (so it can  
> receive bounces).  It doesn't need to be an A record; any record  
> type will do.

If an SMTP domain is valid, one must assume that this domain can  
receive messages.  There is problem when one assumes that just any  
record provides evidence of an SMTP's domains existence.  To send to  
this domain, this requires either an _MX_ or _A_ record be published  
at the SMTP domain.

Basing existence upon A records may run afoul of those ISPs and TLDs  
who inject records when NXDOMAIN would otherwise be returned.   
Considering the SMTP domain as being valid only when there is also an  
MX RR has the advantage of actually ensuring a valid SMTP domain.   
Use of A records for SMTP discovery should be deprecated.  When some  
domain wishes to use random sub-domains, they must also publish a  
wildcard MX.  A query at the random sub-domain will thereby return an  
MX record.  Use of truly random domains precludes the ability to  
publish policy at a random domain, as it should be.

>> 17) Algorithm 4 - "is a top-level domain" how can that be  
>> determined in practice?  I don't think it can can it? If not,  
>> we're giving algorithmic instruction here that is impossible to  
>> implement.
>
> A top-level domain is one that has exactly one component, e.g.,  
> "com", "org", "uk", or "tv".  We also talk about suffixes, which  
> would probably include "co.uk", "k12.ca.us", and "edu.au".  We  
> mandate not querying the top-level domains, since they can be  
> algorithmically determined and we really don't want to  
> unnecessarily load the TLD servers.  Not querying suffixes is  
> optional, as the definition for what a "suffix" is, because there  
> is no formal definition and this is really an optimization.

For the ccTLDs, it is common for second and third level domains to be  
used.  Not all domains are published off of a top level domain.   
Second level domains might then become tempted to publish some SSP  
record to terminate an inordinate level of SSP searches.  Nearly all  
email sent today will cause an unterminated search SSP record search  
by those implementing this flawed algorithm. : (  If SSP supported NO  
MAIL, it would be rather ironic to have SLDs publish an SSP that  
accurately indicated they do not send email.  Use of parent domains  
to establish policy if _flawed_, and should not be used.

>> top-level domains, Algorithm 5 will send lots of queries to the  
>> root servers right (.co.uk for example)?
>
> .co.uk isn't a root server, it's a suffix.

Also known as a Second Level Domain, or SLD.  These are used in a  
manner identical to that of a TLD.  Just as with the TLD, SLDs MUST  
NOT be subjected to the resulting high level of unterminated searches.

> The root servers are the places you query to find the name servers  
> for ".com", ".us", ".hr", and so forth.  It may send quite a number  
> of queries to the .co.uk name servers, which is why you may want to  
> have it in your suffix list, but even if it's not, the number of  
> queries should be limited by the minimum TTL of the zone it's in  
> (the negative caching time).

The algorithm being suggested demands a list of domains used as  
registries be published prior to deployment of such an algorithm.  I  
will to help in creating the draft that documents this list.  Using  
MX records to valid existence and deprecating the use of A records  
for discovery is a better overall strategy however.  It would not  
take long for all domains to publish MX records when their messages  
are not accepted on occasion as a result.

The problem of spam and spoofing is such, that some change to SMTP  
can and should be demanded.  Publishing an MX record is not much to ask.

-Doug

---

From: John Levine <[email-masked]>
Date: 26 Jul 2007 19:37:13 -0000

>there is no formal definition and this is really an optimization.

The abuse.net database lookup does an internal walk up the tree
looking for an entry (in its own database, not the DNS), and I can
report from experience that trying to track delegation point suffixes
is an extremely hard problem.  Things that look parallel often aren't,
e.g., in the various state k12.xx.us domains, in some states there is
one agency that serves all the schools so it's a real domain that
should have a record, while in others it's just a label.  And the list
is highly dynamic, e.g., sakhalin.ru used to be a geographic label,
similar to a lot of other <place>.ru domains, but now they have a
municipal ISP and it has an MX record.

R's,
John