Subject: [ietf-dkim] Next steps for draft-ietf-dkim-ssp

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 Dec 2008 13:20:28 +0200

I've gone through the IETF last call comments for ADSP.

I've understood that the major issues raised by Doug have been
discussed in the WG earlier, and the WG reached rough consensus 
on them. 

If that's the case, I have no problem with it. However, after reading 
Doug's comments together with RFC 4871 and draft-ietf-dkim-ssp-07, 
I think there are some cases where the document needs additional
clarify or details about the decisions that were made.

1) "i=" tag

The terms "Valid Signature from an Author Domain" and "Author
Signature" are very easily confused. If I understood Doug's comments
right, he's essentially proposing making these two terms
identical. That would certainly simplify things, but since the WG has
decided otherwise, we need to make sure the distinction is understood
by the reader. I will send a separate email about this topic.

2) Protecting subdomains

S3.1 is clear that an ADSP record at _adsp._domainkey.domain.example
applies only to emails from that specific domain (domain.example), not
its subdomains.

However, I think we need an additional paragraph explaining the
implications of this choice for domains that would like to protect
their subdomains (for every <X>.domain.example that exists, they have
to deploy ADSP record at _adsp._domainkey.<X>.domain.example), and
give some advice how DNS management tools could do this without either
undue manual effort or wildcards (which are prohibited in S6.3).

3) Scope of ADSP

Doug also commented the sentence "ADSP as defined in this document is
bound to DNS", and suggested changing that to "...DNS and SMTP".

I have a question here: Suppose that some future FooMTP protocol
used e.g. SRV records at "_foomtp._tcp.eng.example.com" to find the 
server for address "[email-masked]" (instead of using MX records).
If all the RRs (including "_foomtp._tcp.eng.example.com") are in the
"example.com" zone (no zone cuts under it), and no RRs with owner
"eng.example.com" exist, does a DNS query for "eng.example.com" return
NXDOMAIN or NODATA?

If I had a DNS server installation at hand, I could of course test
what it returns... but perhaps someone knows the answer already? 
If a query for "eng.example.com" returns NXDOMAIN in this case, then 
saying we're bound to SMTP (or protocols that use DNS records in 
very similar way as SMTP) might be more accurate.

4) Minor clarifications/nits

>From my email on 2008-11-25:

Section 4.1:
OLD:
   The "Tag=Value List" syntax described in section 3.2 of
   [RFC4871] is used.
NEW:
   The "Tag=Value List" syntax described in section 3.2 of [RFC4871] 
   is used, with one minor change: WSP is used instead of FWS.

Section 4.2.1
OLD
   ADSP records use the "tag=value" syntax described in section 3.2 of
   [RFC4871].
NEW:
   ADSP records use the "tag=value" syntax described in section 3.2 
   of [RFC4871], with one minor change: WSP is used instead of FWS.

>From Miguel Garcia's Gen-ART review:

  "Section 6.2 discusses DNS attcks. However, I don't think that the
  second paragraph is discussing a DNS attack. It seems to be
  discussing a regular failure of a DNS server. While I don't disagree
  with the content, it seems that it would be better place in a
  section that is NOT titled "DNS attacks"."

Any suggestions on this?

In Section 1, "Author Signing Practices" probably should be "Author
Domain Signing Practices"

Section 2.7:

   "For example, if a message has a Valid Signature, with the DKIM-
   Signature field containing "i=[email-masked]", then
   domain.example is asserting that it takes responsibility for the
   message.  If the message's From: field contains the address
   "[email-masked]" and an ADSP query produces a "dkim=all" or
   "dkim=discardable" result, that would mean that the message does
   not have a valid Author Signature. Even though the message is 
   signed by the same domain, it fails to satisfy ADSP.

The second sentence seems incorrect. Should this say something
like 

   [...] If the message's From: field contains the address
   "[email-masked]" that would mean that the message does not have a
   valid Author Signature.  If an ADSP query produces a "dkim=all" or
   "dkim=discardable" result, even though the message is signed by the
   same domain, it fails to satisfy ADSP.

Best regards,
Pasi

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

---

From: John Levine <[email-masked]>
Date: 18 Dec 2008 01:42:52 -0000

>Signature" are very easily confused.

I think we're all confused at this point.  If the From: address
were [email-masked] and the signature had i=[email-masked], that
sure looks like a valid signature from an author domain, but I
don't think anyone expects them to match.

Personally, I have never understood the assumption that the i= value
is in the same namespace as From: addresses, since it's demonstrably
false, but I've been consistently overruled so I'll have to let
someone who does understand this model try to fix it.

>their subdomains

We deliberately left this out because it's just a subset of the
impossible problem of defending against lookalike domains.  For the
subdomains you actually use, it's easy enough to publish records for
them so that's not at issue.  We had a long and heated discussion
about protecting all of a domain's non-existent subdomains, but it was
never clear why if you're example.com, it's more important to protect
against foo.example.com than examp1e.com, since we all agree that the
latter isn't possible.

>"eng.example.com" exist, does a DNS query for "eng.example.com" return

It returns NODATA.

>4) Minor clarifications/nits

I think I got the FWS/WSP and DNS Considerations in -08.

Re your second message, we didn't say anything about Sender: for
roughly the same reason we didn't say anything about subdomains -- the
number of identities that ADSP doesn't address is unlimited, and it
seems counterproductive to try to enumerate all of the addresses to
which someone might wrongly hope that ADSP applies.

Note that any valid DKIM signature means that an organization takes
responsibility for the mail it signed.  ADSP doesn't and can't affect
that, so again, there seems little point in listing yet more things
ADSP doesn't do.

R's,
John

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 30 Dec 2008 10:28:45 +0200

> don't think anyone expects them to match.

Maybe, but that expectation is not based on the definition of "Valid
Signature" in RFC 4871 -- so this document needs to be clear about it.

> someone who does understand this model try to fix it.

Since the WG apparently reached rough consensus on this, at this
point I'm not asking anyone to fix it, but just make the explanation
clearer so that readers who didn't see the WG discussions will
understand the implications.

(The main implication being that just signing all your outgoing email
may not allow you to advertise "dkim=all", if you e.g. use the "i="
tag to identify a mailing list manager -- the only example of its use
given in RFC 4871.)

> against foo.example.com than examp1e.com, since we all agree that the

Right -- this is not something we can (or need to) solve in this
document; I was asking for a sentence or two explaining the "it's easy
enough to publish records for [the subdomains you actually use]" part.

Something like this, perhaps? (added after 2nd para in Section 3.1)

   Note: If an organization wants to publish Author Domain Signing
   Practices for all its subdomains, too, it needs to create ADSP
   records for every _adsp._domainkey_.<subdomain>.domain.example.
   Note that wildcards cannot be used (see Section 6.3); however,
   creating the ADSP records could be automated with suitable DNS
   management tools.

> >"eng.example.com" exist, does a DNS query for 
> "eng.example.com" return NXDOMAIN or NODATA?
> 
> It returns NODATA.

Thanks! I think we can leave this sentence as-is, then.

> that, so again, there seems little point in listing yet more things

I think clearly explaining when an organization that signs all
its outgoing email can actually publish a "dkim=all" policy is pretty
important --  although ADSP doesn't (and shouldn't) do everything,
we need to be clear about what it does.

Best regards,
Pasi

---

From: John L <[email-masked]>
Date: Tue, 30 Dec 2008 11:09:12 -0500 (EST)

> tag to identify a mailing list manager -- the only example of its use

Ah, good point.  That's straightforward to fix.

I suppose the alternative, now that we have some experience with i= in 
real life, is to adjust the language in ADSP to match the experience. 
Dunno how the other authors feel about that.

>   creating the ADSP records could be automated with suitable DNS

OK.

> we need to be clear about what it does.

It's when the signature matches the From: address.  Shouldn't be too hard 
to say it again.

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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 30 Dec 2008 12:23:57 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John L
> Sent: Tuesday, December 30, 2008 11:09 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
> 
> 

Wouldn't the better (correct) way to state this be: 

It's when the signing domain (d=) and signature matches the From:
address domain.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 30 Dec 2008 10:15:35 -0800

> It's when the signing domain (d=) and signature matches the From:

That change in language should help, yes.

The distinction between 'email address' and 'email domain name' is often lost. 
Language to emphasize the distinction is probably a good idea for the document.

The fact that i= is defined to identify a user, rather than a mailbox, and that 
the difference is not clear to folks, but that it can be quite large, is also 
proving to be a consistent point of confusion.  For example it can (and 
sometimes does) contain non-mailbox information.  This is what John was 
observing a few notes back.

I'm not sure there is an opportunity to clarify it, in this doc, but it might be 
worth considering.

I'm sufficiently not sure that I don't even have language to suggest.  Sorry.

Perhaps some text that notes that i= MAY match the From: address but that it is 
not required to, even when i= is in the syntax of an email address?

d/

-- 

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

---

From: John L <[email-masked]>
Date: Tue, 30 Dec 2008 13:44:12 -0500 (EST)

>> It's when the signature matches the From: address.  Shouldn't be too
>> hard to say it again.
>

That's what I think, but the current draft has the i= override the d= so 
if the From: is [email-masked], the signature is d=b.com i=[email-masked], then as 
currently spec'ed, that doesn't match.

I'd be happy to change it to say that the d= has to match if nobody else 
has a strong objection.

Regards,

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 30 Dec 2008 14:18:51 -0500

> From: John L [mailto:[email-masked]]
> Sent: Tuesday, December 30, 2008 1:44 PM
> To: MH Michael Hammer (5304)
> Subject: RE: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
> 

This goes back to all the long drawn out discussions when it was changed
from "Sender Signing Policy" to "Author Domain Signing Policy". If we
start talking about the Right hand side then we aren't talking domains
but addresses. 

I was originally in favor of a broader scope for "SSP" that would have
gone beyond just the From: address domain to include other signers. The
narrower scope met what I perceive as the needs of heavily phished
brands so I was comfortable going with the narrower scope. 

The i= override doesn't make sense to me if the intent of ADSP is
signing by author domains. I thought this was why we ended up going with
"all" and "discardable" conceptually. 

Is there anyone on the list that would realistically plan on
implementing/publishing ADSP using an "i=" override? If so, could they
explain the logic and necessity of doing so? What is the anticipated
benefit?

Mike

---

From: John L <[email-masked]>
Date: Tue, 30 Dec 2008 14:26:06 -0500 (EST)

> Perhaps some text that notes that i= MAY match the From: address but that it 
> is not required to, even when i= is in the syntax of an email address?

That would be fine with me, but what it says now is that the i= MUST match 
the From: address.  As I've said a few times, that's clearly wrong, but I 
got shouted down in the past when I tried to change it.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Dec 2008 12:36:16 +0000

> got shouted down in the past when I tried to change it.

Without getting into the merits of the argument (and I don't think we
should do all that again), the document does currently reflect the
WG's rough consensus so let's keep this to adding clarifications as
Pasi requested and not try re-open issues now after the end of IETF
LC.

Stephen.

---

From: John L <[email-masked]>
Date: Wed, 31 Dec 2008 09:13:49 -0500 (EST)

> Pasi requested and not try re-open issues now after the end of IETF

Since I don't understand what the people who want to use i= think it's 
supposed to do, I'll defer to the other authors and them them fix it this 
time around.

Regards,

---

From: "J D Falk" <[email-masked]>
Date: Wed, 31 Dec 2008 19:34:53 -0500

On 30/12/2008 11:15, "Dave CROCKER" <[email-masked]> wrote:

> The fact that i= is defined to identify a user, rather than a mailbox, and

A user, or a use!  But I doubt that makes things any clearer.