Subject: [ietf-dkim] Summary of DKIM jabber meeting on 12 Oct

From: DKIM Chair <[email-masked]>
Date: Thu, 12 Oct 2006 14:51:11 -0400

(As always, if you have comments about this summary itself, leave the
subject as is... otherwise, please change the subject appropriately
when you reply.)

The meeting was called to order at 1505 UTC on 12 Oct.
In attendance were Barry Leiba, Eric Allman, Jim Fenton, Mike Thomas,
Dave Crocker, Peter Koch, Tony Hansen, and Hector Santos.

We briefly discussed issue 1360, "delegation" vs "designation".  We
appear to have support for this from only two WG participants, and
there are drawbacks in terms of complexity of the protocol.  The
chairs' judgement is that we REJECT this issue.  We'll allow some
further discussion on the mailing list, if the proponents want to
continue it (please put the issue number in the subject line).  Lacking
further discussion, or increased support that would show rough
consensus for adding "designation", we'll ask Eliot to close the issue
as REJECT on 20 Oct.

Dave Crocker reviewed five issues that are open in his name, and
confirms that he's waiting to see the next ssp-requirements draft for
all of those.

That left issue 1365, with a question about the "we never send mail"
issue.  The initial proposal was to remove the text, considering it to
be a special case of "strict", but when Doug opened that back on the
list there was significant support to keep it.  I'll put that back out
to the list now (please put the issue number in the subject line): If
you object to leaving it in, please say so and say why.

Peter Koch also points out that he has an action item from the last
chat, to open an item on discovery and tree walking.  He needs to
review the earlier discussion, and has not yet done that.

The meeting was adjourned early, at 1530.

After the adjourment, we had informal discussion of the likely
last-call schedule for -base.  The current status is that Russ Housley
has done his AD evaluation on -base-05, and Eric is preparing -base-06
to address his comments (all minor).  Eric will get that update
submitted ASAP.  The next step will be to deal with IETF-wide Last Call
on the document, which will likely happen soon after the San Diego
meeting.

--
Barry Leiba, DKIM Working Group Chair  ([email-masked])

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

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Oct 2006 10:49:06 -0400

> consensus for adding "designation", we'll ask Eliot to close the issue

I think it would be better to leave it in, but the use cases I was 
particularly concerned about have been addressed, so I no longer think it's 
essential.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Oct 2006 11:02:29 -0400

> you object to leaving it in, please say so and say why.

I think that being able to express 'we never send mail' is important.

There is already one way to express this defined as part of an experimental 
protocol in RFC 4408 that has significant deployment.  While that is a 
controversial protocol in general, I do not think that most of the 
controversy applies to domains that send no mail.  That one piece could be 
broken out in a separate draft without carrying forward the aspects of the 
experimental protocol that some find problematic.

Instead of defining yet another way to express the same thing (which may at 
least be arguably outside the charter of the group), an alternative approach 
might be for this working group to punt 'we never send mail' back to the 
AD/IESG (I'm still hazy on lots of IETF process, so forgive me if that's the 
wrong direction) with a recommendation that this is something the group feels 
will support receivers in evaluating DKIM signed mail, but that the group 
felt was better addressed elsewhere.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 14 Oct 2006 17:38:53 +0100

> felt was better addressed elsewhere.

Just addressing the potential process thing:

If the WG don't include this as a requirement, then the thing to do
would be to write an individual I-D profiling that part of the relevant
experimental protocol. That I-D, or the RFC resulting from it, would
then presumably be part of the input were said experimental protocol
ever to resume on the standards track.

Having said that, our job for now is to figure out whether to include
this requirement or not for SSP, and your mail isn't entirely clear as
to whether you think SSP needs to support that requirement.

Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Oct 2006 12:57:50 -0400

> to whether you think SSP needs to support that requirement.

I'm ambivalent.  I think it [that a domain claims to send no mail] is a fact 
that would significantly aid receivers in evaluating received mail.  I don't 
know that it needs to be defined here.  

I think there is some harm in every e-mail identity related protocol 
re-inventing how to express 'sends no mail'.  I think it would be better to 
do it once.  Given that there is one method that is standardized at least at 
the experimental level, in theory I think it's better not to try and reinvent 
the wheel here.  In practice, I understand that would open a rather large can 
of worms.

Just to be clear, I was suggesting using a TXT record with the sting 
literal 'v=spf1 -all' in it and not suggesting trying to drag the entire 
protocol along.

So, I guess I was unclear because I'm not certain what is best.  I think it 
depends of whether we are more concerned about theory or practice.  I tend to 
be practical, but I could go either way in this case.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Oct 2006 10:06:34 -0700

> to whether you think SSP needs to support that requirement.

The working group is focused on DKIM.  As I understand it, our work on SSP is 
therefore  in support of DKIM.  A flag that says "we never send mail" is not 
specific to DKIM.

SSP is being defined as an extensible mechanism and we are populating it with 
some initial set of DKIM-related flags.  Nothing constrains what flags can be 
added later.

The advantages to producing an independent I-D for a flag that says "we never 
send mail" is that it can use the extensible mechanism, without having to be 
tied to the DKIM working group and without being placed into the critical path 
of initial SSP standardization.

The latter point is made even more significant by the fact that there is an 
existing and deployed mechanism, and therefore there is a reasonable debate to 
have about creating a new one.

All that makes it better to decouple that work.

d/

ps. I'm not offering an opinion about the merits of having this flag, merely 
looking for a way to expedite our core work.

-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Sat, 14 Oct 2006 10:14:52 -0700

> know that it needs to be defined here.

It's a pretty rare case. I think the main
reason it keeps coming up is that it's the only case in which a sender
domain can make a statement that will work reliably (in either SPF
or SSP), so is used as the "But look! It can work in this case!" poster
child to support the need for that sort of protocol, rather than because
many people actually need the functionality (either as senders or
recipients).

> literal 'v=spf1 -all' in it and not suggesting trying to drag the  

If you do that, you're dragging the whole SPF protocol along, whether
you mean to or not, for recipients at least (unless I'm  
misunderstanding,
which is perfectly possible).

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Oct 2006 10:47:48 -0700

On Oct 14, 2006, at 10:06 AM, Dave Crocker wrote:

>
> The working group is focused on DKIM.  As I understand it, our work  
> on SSP is therefore  in support of DKIM.  A flag that says "we  
> never send mail" is not specific to DKIM.
>
> SSP is being defined as an extensible mechanism and we are  
> populating it with some initial set of DKIM-related flags.  Nothing  
> constrains what flags can be added later.

With the ability of a key to be located in a parent domain, the issue  
of repudiation becomes a greater concern when there is a desire to  
thwart phishing attempts.  Fewer delivery issues are created when  
there is an ability to indicate:

1) the specific domains sourcing and signing their messages,

2) their avoidance of services that might damage signatures.

One attack scenario would be a message using a sub-domain email- 
address with a broken signature referencing a valid key.  Without  
these two essential indicators, blocking such messages will likely  
prove highly disruptive for those domains not being phished.   
Excluding sub-domains with an assertion "this domain never sends  
mail" is essential as it permits stricter treatment in this special  
case.   Rather than the misleading "we"  change the statement to  
"this domain does not send mail."   This domain can easily be a sub- 
domain of a phishing target that does use DKIM.  It also seems  
unlikely a domain that does not use DKIM will bother to make such a  
DKIM specific policy statement.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Oct 2006 12:12:27 -0700

On Oct 14, 2006, at 7:49 AM, Scott Kitterman wrote:

> particularly concerned about have been addressed, so I no longer  
> think it's essential.

A designated scheme is still desirable, perhaps even essential.  Use  
of CNAMEs may be seen as an alternative to DNS delegation, but the  
CNAME technique still means:

1) A third-party controls your private key signing as your domain.

2) The DKIM directed feedback will not be sent to the affected domain.

3) Confirmation that CNAMEs are properly implemented may not happen  
prior to signing.

4) Customer signing requires unique keys rather than unique sub-domains.

5) Valid messages without valid keys will become more common.

6) Key roll-over may unexpectedly expose customer configuration errors.

7) Customer's DNS implementation may be internally fragile when the  
reference of a CNAME is assigned a different address.

8) Details related to the selectors used for the customer's domains,  
whether email-addresses are to be asserted as valid, the TTL of the  
keys, and whether this key applies to sub-domains must be exchanged  
prior to signing.

Policy designating a signing domain will not affect the integrity of  
the signing/key relationship.  Designation allows an email-address  
domain owner to independently decide whether their email-addresses  
should be asserted as valid when signed by a provider's specific  
domain.  Designation relationships can be safely established at any  
time in an autonomous fashion fully compatible with most email- 
service arrangements.  The minimal administration needed for  
designation permits scaling to a greater number of customers.   
Designation will increase the integrity of DKIM signed messages.

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 16 Oct 2006 15:25:24 -0400

+1

Sorry.. no time to reitterate what has already been said.

Regards,
Damon Sauer

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Oct 2006 16:20:32 -0400

> 4) Customer signing requires unique keys rather than unique sub-domains.

Not to belabor the overall issue, but this particular point is inaccurate.  
I've done it single key with multiple customer domains and no NS delegation.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Oct 2006 15:35:09 -0700

On Oct 16, 2006, at 1:20 PM, Scott Kitterman wrote:

> Not to belabor the overall issue, but this particular point is  
> inaccurate.  I've done it single key with multiple customer domains  
> and no NS delegation.

You are right.  However, technically both designation and the CNAME  
approach are still seen as providing different keys.  Signing  
referenced from different sub-domains unique to customers can also  
use a common private key.   In the case of the designation approach,  
the provider fully controls the publishing of the keys.  With the  
CNAME approach, the provider depends upon the customer to create  
proper references.

Assuming a reference to policy is avoided with the CNAME approach,  
then both techniques require the same DNS overhead.  Two transactions  
to resolve the CNAME indirection, or one to directly obtain the key,  
and another to obtain a designation policy.  The difference is fairly  
minor from an implementation standpoint, but dramatically different  
from an administrative standpoint.

-Doug