Subject: [ietf-dkim] New Version Notification for draft-ietf-dkim-ssp-04 (fwd)

From: John Levine <[email-masked]>
Date: Wed, 2 Jul 2008 12:42:46 -0400 (EDT)

At long last, here's a new, I hope final, version of the SSP draft.

Notable changes include:

* The name is now ADSP, Author Domain Signing Practices

* Per straw poll, the one-level tree walk is gone.  The flags field in the 
ADSP record is gone, too, since there's no longer any flags.

* Per what I hope is group consensus, lookup process is simplified to say 
that clients MUST do the NXDOMAIN check and MAY do more extensive checks 
to see if a domain exists, and if it doesn't, ADSP doesn't apply.

* Address matching clarified to say that when comparing the author address 
to the signature address, Local-part matches are case sensitive, domain 
matches are not (that's consistent with RFC 821/2821), beyond that it's 
just a string match, in case anyone expected CNAME resolution or other 
canonicalization.

* Discussion of wildcards redone to match lookup procedure. I'm pretty 
sure it's right, so if you disagree, please be specific.

* Whitespace in ABNF is changed from WSP back to FWS, to make it 
consistent with the DKIM spec.  (WSP makes more sense on its own, but I 
think we agree that consistency wins.)

* Lots of minor cleanup to remove unused definitions and the like.

R's,
John

---------- Forwarded message ----------
Date: Wed,  2 Jul 2008 09:34:34 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>

A new version of I-D, draft-ietf-dkim-ssp-04.txt has been successfuly submitted by John Levine and posted to the IETF repository.

Filename:	 draft-ietf-dkim-ssp
Revision:	 04
Title:		 DKIM Author Domain Signing Practices (ADSP)
Creation_date:	 2008-07-02
WG ID:		 dkim
Number_of_pages: 19

Abstract:
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages.  This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address.  It defines a
record that can advertise whether they sign their outgoing mail, and
how other hosts can access those records.

The IETF Secretariat.

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2008 19:39:46 -0700

3.1.  ADSP Applicability
4.3.  ADSP Lookup Procedure

Verify Domain Scope:

This draft imposes a requirement that a domain within a From email- 
address is to be found within DNS.  This requirement is intended to  
provide a domain control over the ADSP default assertions made below  
their name hierarchy.  However, excluding domains without known TLDs  
could be inappropriate as well.  What is also excluded from this draft  
is a definition for specific protocols where the domains are expected  
to be supported.

NNTP might use a TLD of .invalid to ensure an address is not mistaken  
for a valid email-address.  Micros~1 Exchange permits use of X.400  
email-addresses aliased to a domain name assigned via their registry  
without existing within DNS.  In addition, there is nothing within  
this draft to suggest that the ADSP assertions are limited to messages  
publicly exchanged over SMTP port 25.  This draft should warn ADSP  
DKIM signature expectations may affect other protocols converted and  
then bridged into SMTP, or those received over other protocols by MUAs.

In addition, the suggestion to use wildcard domains to publish ADSP  
TXT records necessitates exclusion of domains without valid host name  
syntax.  This draft tangentially refers to RFC2821, but only with  
respect to case-insensitivity.  Do not expect wildcard domains will  
defend against chosen-name.*.example.com, or chosen- 
name._domainkey.example.com, for example.  These exploits can be  
prevented by insuring valid host name syntax.

Add:

ADSP defines a record that can advertise the extent to which a domain  
signs outgoing mail that is publicly exchanged on SMTP port 25, as  
described in [RFC2821]. Also, how other hosts can access those records.

Advertisements, defined by this document, may also increase DKIM  
signature expectations for messages received by Mail User Agents  
(MUAs) or for messages which might have been exchanged over protocols  
other than SMTP. In some circumstances, author domains may wish to  
have accommodations for protocol failures or for mixed public protocol  
messaging not to be made.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 07:53:36 +0200

Douglas Otis wrote:
 
> NNTP might use a TLD of .invalid to ensure an address is not
> mistaken for a valid email-address.

It doesn't.  Individual NNTP servers might allow this, as far
as they check From: email-addresses at all.  Likewise individual
receivers behind a news2mail gateway might allow this, as far
as they check From: email-addresses at all, not limited to ADSP.

TLD ".invalid" in conjunction with the text "valid mail domain"
is clear.  If not the poor reader needs medical help, not more
text in the draft.

> the suggestion to use wildcard domains to publish ADSP TXT 
> records necessitates exclusion of domains without valid host
> name syntax.

AFAIK it doesn't.  A, AAAA, MX, or TXT records are not limited
to valid host name syntax.  That the draft only discusses the
case of MX wildcards might be an issue.  But I think readers
should be able to figure out that it's also applicable to AAAA
and A wildcards.

The statement "multiple wildcard records produce an undefined
ADSP result" is odd.  Defining a proper "subtype" to find the
wanted ADSP needle in a TXT RR haystack is no rocket science.
We can get an IAB review if necessary.

> These exploits can be prevented by insuring valid host name
> syntax.

What has host name syntax as required for 2821bis and 2822upd
to do with wildcards, another DNS oddity I'm not aware of ?
Anything that is no host name can't be a "valid mail domain".

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 03 Jul 2008 10:51:58 +0100

> messaging not to be made.

That seems a convoluted way of dealing with the issue, and it seems to  
place the whole responsibility on the author domains (with no suggestion  
as to what "accomodations" they might employ), rather than on the  
Verifiers (actually, it requires a degree of common sense by both of them).

I earlier suggested a wording on the following lines:

I would suggest all that is needed in the present draft is a statement
that the existence check MAY be omitted in the case of TLDs that are known
not to exist in the global DNS system, with a pointer to RFC 2606 for some
examples (not to be construed as an exhaustive list). That leaves it to
Verifiers to use their Common Sense. Maybe a future document would make it
more specific, but that would cover us for now.

-- 
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