Subject: [ietf-dkim] AD evaluation comments for draft-ietf-dkim-ssp

From: "[email-masked]" <[email-masked]>
Date: Mon, 20 Oct 2008 11:57:18 +0300

Hi,

I've done my AD review for draft-ietf-dkim-ssp-06, and I was happy
to see that the document is in good shape.

I do have couple of suggestions, though. Basically all of these are of
"the WG members probably understand what this text means, but if you
could add couple of more words, future readers would be thankful"
type; that is, suggestions for improving the clarity especially to
folks who didn't read the WG discussions about the topic.

Stephen, could you as the document shepherd take the lead in
discussing these and getting agreement on appropriate edits? 
(in some cases, I've suggested a possible wording, but that's 
just one starting point)

Best regards,
Pasi

------

- Section 3.1: to some folks, "domain" means just a single DNS name
  "example.com"; to others, it might mean everything under
  "example.com". I think it'd be useful to give a concrete example
  here, saying e.g. that an ADSP record for "example.com" (stored in
  _adsp._domainkey.example.com) does *not* apply to emails from
  e.g. [email-masked] ; to cover that, you'd need 
  _adsp._domainkey.www.example.com etc. (IMHO this is quite important 
  detail that isn't currently isn't very obvious from the document.)

- Section 3.3, 1st bullet would be clearer if it said
  "...no ADSP record is found"

- Section 3.3, 3rd bullet: this would be easier to understand if you
  copied the text from 4.2.1 definition of "discardable" here, too.

- Section 3.3, 4th bullet: this would be easier to understand it
  said "because it does not exist in DNS", "this is the case if
  the domain does not exist in DNS", or something

- Section 3.3, should mention the 5th possibility of the procedure in
  4.3: algorithm terminates without producing a result, indicating a
  temporary failure.

- Section 4.1 says the "Tag=Value List" syntax from RFC 4871 is used,
  but it seems there's a difference: 4871 uses "[FWS]" around the "="
  sign, while this document uses *WSP. This is probably an intentional
  difference (right?), but should be explicitly pointed out.

- Section 4.2.1: Since the signing practice list is extensible, the
  text should say how an unknown value should be treated -- probably
  same as "unknown"?

- Section 4.3, "Check Domain Scope" step: it'd be useful to explicitly
  say something "NODATA" (rcode=0 with ANCOUNT=0), as if I recall right,
  even some WG members were confused at some point...

- Section 4.3, "Fetch Named ADSP Record" step: it'd be useful to say
  here that if the result is NXDOMAIN, or NOERROR with zero records, or
  NOERROR with records that aren't valid ADSP records, the result is
  "unknown" (is that right, BTW?)

- Section 4.3, "does not exist for mail" would benefit from 
  rephrasing somehow (perhaps "is not a valid email domain for
  [2821]", or something?)

- Section 4.3: would this be easier to read if you included a concrete
  example (e.g. email message with a From line, and all the DNS lookups
  done)? Or perhaps couple of examples?

- Section 6.1, last paragraph: to me it seems the amount of DNS
  traffic would be less than amount of SMTP traffic, so this wouldn't
  be a very good traffic multiplication attack? (with multiplier < 1)
  If that's the case, perhaps would be useful to mention?

Nits:

- Title: Expand acronym DKIM 
- References: update RFC 2821 to 5321, and 2822 to 5322 
- Section 4.1, "the_adsp._domainkey" -> "the _adsp._domainkey"

------

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Oct 2008 11:07:32 +0100

Thanks Pasi,

I'll work with the authors to get their reactions back to the list
and we can go from there,

Cheers,
S.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Oct 2008 11:26:25 -0700

On Oct 20, 2008, at 1:57 AM, [email-masked] wrote:

There is an alternative to the use of DNS existence that will allow  
use of wildcards and will not necessitate DNS existence tests.  The  
alternative would be to define ADSP as applying to RFC5321.

> - Section 3.3, 1st bullet would be clearer if it said  "...no ADSP  
> record is found"

This would be incorrect.   As currently defined, the ADSP draft  
requires any From header field domain to exist within DNS.  Existence  
checks apply to all email, and are not limited to domains publishing  
ADSP records!

> said "because it does not exist in DNS", "this is the case if the  
> domain does not exist in DNS", or something

When the From header field does not exist within DNS,  the domain is  
"out-of-scope".   For this to control abuse,  "out-of-scope" will need  
to be interpreted as having the same state as 3rd bullet!

Again, defining ADSP as applying to RFC5321 eliminates a need for the  
dubious "out-of-scope" state, since ADSP would only be valid for  
domains that support RFC5321.

> - Section 3.3, should mention the 5th possibility of the procedure  
> in  4.3: algorithm terminates without producing a result, indicating  
> a  temporary failure.

A temporary failure would be a mistake.  The lack of DNS records for a  
 From header field domain is unlikely to change at a later time.

> text should say how an unknown value should be treated -- probably   

While this list might be considered extensible, an "unknown" status is  
unlikely a desired default.  Extensions are likely to require the use  
of a different tag.

> - Section 4.3, "Check Domain Scope" step: it'd be useful to  
> explicitly  say something "NODATA" (rcode=0 with ANCOUNT=0), as if I  
> recall right,  even some WG members were confused at some point...

It seems odd that ADSP fails to mention the use of RFC5321, but then  
goes into describing the DNS protocol API and what is meant by  
NXDOMAIN?  A valid domain is already defined by RFC5321 section 2.3.5  
Domain Names, and 5.1 Locating the Target Host!

There is no current requirement that From header field domains resolve  
servers using DNS.  This field may resolve servers that do not depend  
upon DNS, such as Microsoft Exchange.  ADSP failing to define what  
"out-of-scope" processing means obscures the conflict created for all  
email, and not just email from domains publishing ADSP records.

> - Section 4.3, "Fetch Named ADSP Record" step: it'd be useful to  
> say  here that if the result is NXDOMAIN, or NOERROR with zero  
> records, or  NOERROR with records that aren't valid ADSP records,  
> the result is  "unknown" (is that right, BTW?)

Per section 4.3 4.3 ADSP Lookup Procedure, an NXDOMAIN result is  
defined as being the "out-of-scope" state.  In essence, some sort of  
message processing based upon whether the From header field resolves  
resource records in DNS.

> rephrasing somehow (perhaps "is not a valid email domain for   

Agreed.  The changes being recommended by http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-03.txt 
  removes a need to impose domain requirements for the From header  
field.  These changes allow the positive evidence of RFC5321 support  
to remove the confusion created by the lack of defined resource records.

> - Section 4.3: would this be easier to read if you included a  
> concrete example (e.g. email message with a From line, and all the  
> DNS lookups done)? Or perhaps couple of examples?
>

Wrong.  Due to wildcard related issues and the lack of defined  
specific DNS resource records that pertains specifically to ADSP  
processing, a fair amount of DNS traffic might be generated when  
recipients attempt to mitigate issues created by wildcards.

There are no limits as to the number of signatures that might be  
applied to a message, and there can be a number of parent domains  
where a wildcard might be published.  ADSP even requires multiple  
signatures where one previously could have been sufficient whenever an  
"on-behalf-of" conflicts with ADSP's Author Signature definition.   A  
minor change to the Author Signature definition safely eliminates a  
need for an additional signature.

The general goal of ADSP should be to ensure that the signing domain  
controls the From header field. MTAs and MUAs must interpret which  
message elements relate to DKIM signature's "on-behalf-of" and domain  
before applying annotations or weighing acceptance.  ADSP should only  
require that a DKIM  signature by an authoritative domain be present.   
Whether the From header field is able to resolve an RFC5321 server is  
a separate, and essentially new requirement, that does not belong in  
ADSP draft at all.

-Doug