Subject: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Dec 2005 22:17:34 +0000

Ted Hardie wrote:
> At 9:07 AM -0500 12/21/05, Tony Hansen wrote:
> 
>>I would be happy with the text that was used in the xmpp charter:
>>
>>	Although not encouraged, non-backwards-compatible changes to the
>>	basis specifications will be acceptable if the working group
>>	determines that the changes are required to meet the group's
>>	technical objectives and the group clearly documents the reasons
>>	for making them.
>>
>>This text still keeps the bar high for unnecessary changes, was already
>>vetted through an existing charter, and helped us through a similar
>>impasse when xmpp was chartered.
>>
>>	Tony Hansen
>>	[email-masked]
> 
> 
> I agree with Tony on the benefits of re-using this language, and 
 > it certainly works for me.

Me too FWIW.

Stephen.

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Dec 2005 18:36:27 -0500

Ted Hardie wrote:
> I agree with Tony on the benefits of re-using this language, and it certainly works for me.

Then it sounds like we have some text that we can compromise on.  Jim
Fenton has already said that this text covers his concerns about as well
as what we had, Stephen Farrell has accepted it, and now I'm weighing in.

I suggest that the IESG replace that paragraph in the proposed DKIM
charter with the paragraph above, and that we move on from this topic
to any others that need to be dealt with.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Dec 2005 15:59:00 -0800

Fellow DKIMers,

 > to any others that need to be dealt with.

Well, I guess no one else is concerned about the sequence that has just 
taken place.

We carefully develop charter language through two, complete, multi-month 
rounds of open collaboration, including significant focus on exactly the 
language in question, both times.

Some folks come in at the late stage of the second open process and seek 
to change this text, but they fail to develop support.

So they re-assert their concerns again during the IETF charter last 
call, and now the chairs quickly concede the change, even before getting 
support from the rest of the group.

It's not that the proposed language is bad, it is that this sequence 
bodes rather poorly for dealing with further demands from folks who fail 
to gain support.

And it does not help that two of those doing the (re-)demanding are area 
directors and another an IAB member, raising the fear that the current 
concession is strictly to appease the authority those folks have.

All this with no specific technical concerns driving the demand.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 19:07:11 -0500

>> I agree with Tony on the benefits of re-using this language, and it 

It does not work for me.  It is biased in the wrong direction.  It is 
entirely inappropriate to encourage the WG to produce output that is 
compatible with a specification that is known to have significant flaws.

Consider also the following:

a) we already know that incompatible changes are necessary, thus 
verifying software will need to be upgraded

b) as DKIM is specifically NOT intended to provide assurances of message 
authenticity for more than a few days, compatibility with existing 
signatures is of little consequence anyway

> to any others that need to be dealt with.

I suggest the IESG replace the paragraph with the following:

While it is understood that the WG will use the current DKIM 
specifications as a starting point, the WG is neither expected nor 
constrained to specify a standard which is compatible with those 
specifications.  The WG should feel free to make whatever changes are 
necessary to produce a specification that is robust with respect to the 
requirements and flexible enough to support a diverse set of usage 
scenarios.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: "Arvel Hathcock" <[email-masked]>
Date: Wed, 21 Dec 2005 20:39:54 -0600

> So they re-assert their concerns again during the IETF charter last call,
> and now the chairs quickly concede the change, even before getting support
> from the rest of the group.

Although I also agree with Jim (and others) that the XMPP text is just about
the same as our existing text, watching these events unfold has drawn into
question my understanding of the rules so I need some clarification (sorry,
I'm a newb).  I don't understand how consensus is determined prior to the
acceptance of a change to which (I had thought) substantial consensus had
already been established.  It's clear to me that the Vancouver BOF
established overwhelming support for *something*.  I had thought that
*something* was a WG governed by the charter text which was offered at the
BOF.  Am I wrong here?  If so, then what (if anything) was established by
the humm I heard in Vancouver?  If I'm right, how can a new concensus
significant enough to overturn that demonstrated in Vancouver possibily be
established on the postings of two or three individuals?  Wouldn't you need
everybody who hummed in Vancouver to post "I changed my mind" to this list
first?   So, I just want to understand the process.

-- 
Arvel Hathcock
CEO, Alt-N Technologies, Ltd.
http://www.altn.com

---

From: Andrew Newton <[email-masked]>
Date: Wed, 21 Dec 2005 23:02:38 -0500

On Dec 21, 2005, at 9:39 PM, Arvel Hathcock wrote:

> I'm a newb).

That's quite alright.  There aren't too many RFC lawyers around.  And  
while I have yet to pass the bar, I believe Dave is speaking of  
events that are irrelevant.  From RFC 2418, Section 2.2:

    The formation of a working group requires a charter which is
    primarily negotiated between a prospective working group Chair and
    the relevant Area Director(s), although final approval is made by  
the
    IESG with advice from the Internet Architecture Board (IAB).

And from Section 2.3:

    Once the Area Director (and the Area Directorate, as the Area
    Director deems appropriate) has approved the working group charter,
    the charter is submitted for review by the IAB and approval by the
    IESG.  After a review period of at least a week the proposed charter
    is posted to the IETF-announce mailing list as a public notice that
    the formation of the working group is being considered.  At the same
    time the proposed charter is also posted to the "new-work" mailing
    list.  This mailing list has been created to let qualified
    representatives from other standards organizations know about  
pending
    IETF working groups.  After another review period lasting at least a
    week the IESG MAY approve the charter as-is, it MAY request that
    changes be made in the charter, or MAY decline to approve chartering
    of the working group

    If the IESG approves the formation of the working group it remands
    the approved charter to the IETF Secretariat who records and enters
    the information into the IETF tracking database.  The working group
    is announced to the IETF-announce a by the IETF Secretariat.

Also, relevant to this entire discussion is this tidbit from Section  
2.1 under Criteria for Formation:

     - Is the proposed work plan an open IETF effort or is it an attempt
       to "bless" non-IETF technology where the effect of input from  
IETF
       participants may be limited?

-andy

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Dec 2005 23:13:05 -0500

Dave Crocker wrote:
> and now the chairs quickly concede the change, even before getting 

'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as
some of the rest of the group.  It also seems to me that no one has made
me the boss, so what I suggested was just that: a suggestion.  You may
feel free to spend more time arguing about that paragraph if you like.
My opinion (and that's all it is) is that that's not useful.

I understand the principle you're fighting for, Dave.  And I think it
will come up again, which is why you're fighting it.  I think it will be
better to fight it later, if necessary.

Barry

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Dec 2005 23:54:56 -0800

We have had three proposal for some text on changes to prior work, the
current proposed charter, the text from the XMPP charter, and the text Keith
provided below.

The question that I think IESG should be asking themselves is how is this
similar and/or different from other groups the have chartered or will in the
future. Nearly every group has some people with a fairly strong idea of at
least one way to solve the problem. Without this, it is usually not clear
the work is even possible. Now some groups, XMPP for example, perhaps TLS
long ago, have substantial deployment with difficult backwards compatibility
questions - theses situation might require the charter to provide more than
normal limitations to the scope of the solutions that are possible. I'm
failing to see that dkim has existing deployments or difficult backwards
compatibility problem that would cause the need for some special text in the
charter more than you average WG. (They do have difficult backward
compatibility problems with existing email systems and I like the text that
limits the scope on that.) My current understanding is that the deployments
are small enough that changes are still easy and that non backwards
compatible changes are already expected. I fail to see the analogy to XMPP
but perhaps there is a good reason for something more like XMPP. I'd sure
want whoever approved this charter to be able to give me a clear reason why
they though this WG would produce better work by having this constraint.
It's going to set a precedent for things to come.

Practically speaking, I'm not sure it will make much difference to the work
that the WG produces. If the individuals that will form the WG feel that the
WG has consensus that they will not make changes beyond a a certain
boundary, they don't need the charter to set that boundary. The strong
arguments that this needs to be in the charter makes me wonder if the
individuals that will form the WG will agree to very limited changes or not.
If they will, it's barely worth arguing for here.

Related to how much the charter pre-supposes the solution, the sentence that
"Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy." seems like a pretty heavy
constraint on the possible solutions and one that some proposals disagreed
with. 

I'm not arguing against the current dkim drafts, I am arguing that the
future of doing internet drafts should not be a process where we come to
agreement in a dark and smokey room with a small group of people then set up
WG where effectively only syntax level changes can be made. If we like these
drafts as is, let's skip the WG and just take them forward as AD sponsored
individual drafts and call it done, if we think we need a WG, allow it to
have change control to select a reasonable solution to the problem.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 22 Dec 2005 09:51:58 +0100

Branching off from the interminable "justifiable changes" thread....

--On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings 
<[email-masked]> wrote:

> Related to how much the charter pre-supposes the solution, the sentence
> that "Public keys needed to validate the signatures will be stored

I think this is part of "divide and conquer" that is generally argued to be 
an useful strategy in the IETF: once we buckle down and start writing 
specs, we're documenting one approach, with one set of advantages and 
disadvantages, and are trying to prove that *this approach* is feasible. We 
did that to (I believe) OSPF, IPNG after the "pick one" round, PKIX (vs 
SPKI), IM when it was split into SIMPLE and the 2 alternatives (with XMPP 
being a late 4th) and so on. Each of these groups could regard the "what 
are the alternatives" question as out of scope.

I think that's a good way to get things out the door in a reasonable 
timeframe; I also think that the IETF at the moment lacks venues for the 
(probably interminable) discussions about what approaches to a problem 
exists and whether there are non-chartered alternatives that are worth 
following up - but I think the approach of chartering a WG to look at one 
and only one approach is a reasonable one.

                 Harald

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:27:43 -0500

>> constraint on the possible solutions and one that some proposals 
>> disagreed with.
> 
> I think this is part of "divide and conquer" that is generally argued to 
> be an useful strategy in the IETF: once we buckle down and start writing 
> disadvantages, and are trying to prove that *this approach* is feasible. 

Sometimes feed-forward _is_ useful, and I would agree that the use of 
DNS to store public key information is one of the fundamental 
assumptions behind DKIM.  Change that assumption and you will probably 
produce a system with very different characteristics than DKIM is 
currently assumed to have.

OTOH, the assumption that _all_ public keys used to validate DKIM 
signatures will be stored in DNS is a very limiting one, because it 
appears to lead to either

a) a constraint that policy be specified only on a per-domain basis 
(which is far too coarse for many domains) or

b) a situation that large numbers of DNS queries may be required to 
validate a single signature

I'm comfortable with having a domain's "root public keys" stored in DNS 
but allowing the corresponding "root private keys" to sign key 
certificates for "individual public keys" that can be included in 
DKIM-signed messages.  The policies for use of those public keys can 
then be encoded in the certificates, allowing those policies to be 
specified on a per-user basis.  This gets out of the trap of having to 
specify policy on a per-domain basis, and doesn't require any more DNS 
queries than current DKIM.  IMHO it would make DKIM much more flexible 
and adaptable to diverse domain situations (and thereby much more 
acceptable as a standard) than the current proposal.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Dec 2005 13:40:26 +0000

Keith,

> acceptable as a standard) than the current proposal.

If there were an I-D describing such a protocol, I'd be interested in
reading it - is there one?

Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 22 Dec 2005 05:42:06 -0800

To take a brief detour away from the political and towards the operational...

Can anyone pick a date (or month, or year) for "It would be sensible
to plan on deploying DKIM on our production servers by this date"?

Also, can anyone give a very short summary of the current status of
DKIM that's suitable for giving to people who want to start deploying
some form of authentication, inbound or outbound, but don't need or
want to know about how the sausage is made in any great detail?

Ditto for "Why DKIM isn't DK"?

Cheers,
  Steve

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:47:13 -0500

> charter more than you average WG.

The need for special text is not due to existing deployments or 
backwards compatibility problems; it is due to the existence of a small 
number of individuals who have a history of arguing quite forcefully 
that certain design decisions are carved in stone, despite the problems 
caused by those decisions and the lack of any working group consensus on 
  those decisions.  Said individuals have also been known to make 
misleading statements to support their arguments.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:49:03 -0500

> reading it - is there one?

Not yet.  But it hardly seems like the time to write an I-D when there 
is at present considerable effort being invested to preclude such an I-D 
being considered by the group.

Keith

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 06:35:47 -0800 (PST)

On Thu, 22 Dec 2005, Keith Moore wrote:

> Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to 
> store public key information is one of the fundamental assumptions behind 
> DKIM.  Change that assumption and you will probably produce a system with 
> very different characteristics than DKIM is currently assumed to have.

Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advantages and unlike DKIM or DK does not put serious extra
pressure on DNS infrastructure - which while very capable of serving data 
like ip addresses (i.e. fixed size small data) would not work so well for 
when data served & answer would either come close to or exceed 512bytes 
UDP limit.

But fingerprints (hash of public key) are finite and small pieces of data
that are the same size no matter of public key size has to be larger or
smaller and with this size being close to that of ipv6 address. Additionally
having public key available with a message brings some additional advantages
and allows for optimized algorithms during verification.

As I noted the group forcefully removed considerations of such alternatives
based on the charter and I consider this to be a disadvantage to community.

> OTOH, the assumption that _all_ public keys used to validate DKIM signatures 
> will be stored in DNS is a very limiting one, because it appears to lead to 
> either
>
> a) a constraint that policy be specified only on a per-domain basis (which 
> is far too coarse for many domains) or
>
> b) a situation that large numbers of DNS queries may be required to validate 
> a single signature

Its rather likely that it would lead to both.

> I'm comfortable with having a domain's "root public keys" stored in DNS but 
> allowing the corresponding "root private keys" to sign key certificates for 
> "individual public keys" that can be included in DKIM-signed messages.  The 
> policies for use of those public keys can then be encoded in the
> certificates, allowing those policies to be specified on a per-user basis.

You can just use X.509 certificates and retrieve them from HTTP with SRV
records being used to confirm location of domain's root certificate. That 
walso one of the other alternatives (and the one I used for my proposal)
and yes, it does make it much easier to do per-user policies & signatures.

> This gets out of the trap of having to specify policy on a per-domain basis, 
> and doesn't require any more DNS queries than current DKIM.  IMHO it would 
> make DKIM much more flexible and adaptable to diverse domain situations (and 
> thereby much more acceptable as a standard) than the current proposal.
>
> Keith
>
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Dec 2005 10:32:55 -0500

> (which is far too coarse for many domains) or

Actually, the DKIM base spec does provide a mechanism for replacing the
DNS keystore with something else.  Look at 1.4 for a general statement,
and the description of the "q=" tag in 3.5.  DKIM's intended to be able
to support user-level keys in a future version (there's some discussion
of that in appendix A), and its design is set up specifically not to
prevent that.

The proposed charter puts the details of other key management systems
and user-level keys out of scope so that we can contain the work at this
stage, and make quick progress on the first version.  It'd be entirely
reasonable to recharter and attack these issues immediately after
completing the first round of chartered work, if there are enough people
who want to work on that.  Or we can see how a while of deployment goes,
and form another WG in a year or so to do it.

Barry

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 07:45:02 -0800 (PST)

> of that in appendix A), and its design is set up specifically not to

The spec basicly says that you must support DNS public key distribution
and authorization; that something else may also be added later will not 
change requirement for pki in dns and will only be usefull for those
who can support it as alternative way to retrieve the key (which means
the key would still need to be made available through dns for those who
do not).

It is really no brainer to see that if we have several authorization 
meachanisms a set of them would have to be done as a required for those
creating implementation in order for them to be used and that means 
working on all that as part of the main work on the system and
releasing together with other documents on the signature system.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 07:48:10 -0800

> want to know about how the sausage is made in any great detail?

The DKIM working group charter has been submitted for comment by the 
IETF community.  Chartering the working group will, therefore, shortly 
be considered by the IESG.  They might approve the charter.  If they 
don't, it is anyone's guess about when (or whether) the group will get 
chartered.

The current charter schedule specifies an extremely aggressive schedule. 
  Given the pattern that has already been solidly established, the group 
will not meet it. (For reference, I believe the schedule specifies a 
delivery of the core document faster than the IETF record.)

Given that it is taking somewhere around 6 months to get chartered and 
given the reasons for its taking that long, I'm going to predict that 
the core document will like reach RFC status in 2 years.  That is about 
3 times longer than the charter calls for.

Most folks will disagree with that estimate.

They need to respect history more.

d/

-- 

  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 11:38:44 -0500

> and form another WG in a year or so to do it.

I disagree.  The first standard version of DKIM needs to be something
that is broadly applicable, not something that just handles a few
corner cases.  The amount of stress associated with getting closure and
consensus on a document is sufficiently large (independent of the
document scope) that it doesn't seem like a good idea to waste all of
that effort producing a first document that is of limited applicability,
and that will need to be updated soon - particularly when a lot of the
division within the group stems from the current DKIM spec's
overconstraining the problem.   

If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.  
Let one subgroup work on per-domain keying, key management, and
policies; another subgroup work on per-user keying, key management, and
policies; another subgroup work on message canonicalization; another
subgroup work on specifying signature and hash algorithms (and managing
the transition from weaker to stronger algorithms as these are
discovered); and finally, have a coordination team responsible for
making everything fit together and managing the framework (definitions,
header field names,  parameter names, keywords) that all of these
pieces fit into.  Give each subgroup a year, with deliverables at 4
month intervals.  After a year, expect to do working group last call on
all pieces and start polishing the drafts for final publication.  If
any piece proves to be unworkable, it can be thrown out after a year.
But even if that piece needs to be replaced from scratch and this
causes a delay that's better than imposing a serial dependency a
priori.  The unworkable piece could as easily be per-domain keying as
per-user keying.

I believe this approach will produce a consensus far more quickly than
the serial approach, and that the resulting standard will be more
broadly applicable and more robust.

Keith

---

From: "Arvel Hathcock" <[email-masked]>
Date: Thu, 22 Dec 2005 10:37:04 -0600

> The proposed charter puts the details of other key management systems and 
> user-level keys out of scope so that we can contain the work at this 
> stage, and make quick progress on the first version.

Amen!  I absolutely think this is the right thing.  If people want to spend 
time on alternative key management systems let them write an I-D and input 
that into a future process.  Not now, please.

-- 
Arvel

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 13:45:11 -0500

[recipient list trimmed]

> >  We have already agreed to -- and incorporated -- a
> > substantial backward incompatible change (the canonicalization)
> > due to feedback (and threats) we got. What I'm hoping for
> 
> We have agreed to the addition of an enhancement that provides a good 
> alternative to the existing set of two algorithms.
> 
> That is quite different from tossing out over-the-wire backward 
> compatibility.
> 
> I have not seen the group agree that a sender of an (ESTG) DKIMv1 
> signature will fail with an (IETF) DKIMv2 validator.

I don't know why it would be in anyone's interests to prohibit a
validator of new signatures from also validating old signatures.  That
doesn't mean, of course, that recipients or agents acting on their
behalf should assign the same meaning, or invest the same degree of
trust, in old signatures and new signatures.

Keith

---

From: Jim Fenton <[email-masked]>
Date: Thu, 22 Dec 2005 11:00:27 -0800

> signature will fail with an (IETF) DKIMv2 validator.

Dave,

'nowsp' canonicalization does not exist in "DKIMv2" (-base-01).  It was
eliminated, rather than deprecated, because it created a vulnerability. 
While some -base-01 verifiers may implement legacy nowsp support, a
fully compliant -base-01 verifier may not work with a -base-00 signature
that uses nowsp canonicalization.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Dec 2005 11:13:36 -0800

> different aspects of the problem in parallel rather than serially.

My concern regarding the charter is related to inclusion of the SSP  
draft, which can impose significant disruption.  In my view, DKIM  
should be seen as aspect of the SMTP transport.  Having a signature  
at the transport qualifies sources of email, but should not constrain  
use email-addresses.  Schemes related to the email-address such as S/ 
MIME or OpenPGP are designed to support email-address limitations.   
On the other hand, DKIM purports to offer S/MIME or OpenPGP like  
features for a sub-set of domains willing to disrupt normal email  
practices.

The premise for DKIM protection assurances is based upon visual  
examination of the email-address.  This seriously flawed concept  
already demands most MUAs change.  Even the body-length option pre- 
supposes there is some type of MUA modification.  With DKIM sans SSP,  
the MUA would be able to recognize prior correspondents without any  
other exchange of information.  In some cases, an MTA could use this  
recognition to exclude some abusive traffic based upon prior  
recognitions.  The MUA should be able to safely signal source  
recognition, but signaling adherence to some authorization would only  
place recipients in peril.

SSP, just as with Sender-ID, requires email-address domain owners  
authorize the source of their email, where signatures are transposed  
for address lists.  To allow existing practices, open-ended  
authorizations are required.  The danger from this approach has been  
made apparent by those willing to hold any sort of authorization  
accountable for abuse seen.  There can be no promise that  
authorizations can be open-ended to support existing practices.   
Reputation schemes bolstered by having "authenticated" the identifier  
when finding an authorization record will quickly preclude use of  
open-ended authorizations.

When only a few domains publish the closed-ended authorization  
records for SSP, looking for policy for the majority of email will  
then require that label trees be climbed, where none of this effort  
can be effectively cached.  The solution for this rather broken  
strategy is to create records that indicate open-ended authorizations  
to mitigate the search.  These nonsense open-ended records however  
expose the email-address domain owner to unfair reputation schemes  
already in place.

Details have been published for "compatible" extensions to DKIM that  
improve upon source recognition, abating abusive message replay,  
locating compromised systems, limiting the number of signatures per  
message, establishing expectations for specific email-addresses being  
signed, without requiring any additional lookups in most cases.

http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt

The WG should be limited to establishing the base DKIM signature.   
This signature should be viewed as an aspect of the SMTP transport to  
differentiate it from S/MIME and OpenPGP.  Another WG should make  
efforts related to the MUA incorporating the protections offered by  
DKIM in an opportunistic fashion.  In essence, everyone becomes their  
own certificate authority based upon individual email source  
identifiers offered by DKIM.  Recipients would be able to confirm the  
validity of the correspondent through out-of-band identifications of  
the source.  This could be simply an expected confirmation when  
initially establishing a relationship.  Once the initial identifier  
has been accepted by the recipient, messages could be safely  
highlighted as coming from a recognized source.

There can never be a safe indication based upon a domain used in the  
email address as having authorized the message.  There must be more  
consideration given for the use of unicode.  One only needs to  
investigate the number of look-alike characters in Chinese to  
understand the fallacy of that assurance.  Even the individual that  
does not understand the difference between online.bigbank.com and  
online-bigbank.com could be protected by a recognition scheme.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 11:20:30 -0800

> eliminated, rather than deprecated, because it created a vulnerability. 

sorry. i had misunderstood that line of discussion.  and, yes, 
vulnerability counts as a showstopper.

> that uses nowsp canonicalization.

ack.

that still leaves useful over-the-wire compatibility, doesn't it?

d/

-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 21:06:42 +0100

Douglas Otis wrote:

> DKIM should be seen as aspect of the SMTP transport.

IBTD.  Trying to find any feature in DKIM not covered by the
existing SMTP schemes (MTAMARK, CSV, SPF, but not PRA) it's
_independence_ of SMTP that fascinates me in DKIM.  All you
need is the header, a piece of software, and DNS.  It could
also work for news if we get the FWS canonicalization right.

> Schemes related to the email-address such as S/MIME or
> OpenPGP are designed to support email-address limitations.

Maybe they missed the point, mail without signature.  A simple
way to publish that all mails claiming to be from X are spam
if they don't have X's signature.  [ I'm just spamcop-ping 36
phishes claiming to be from my bank, hilarious ]

> SSP, just as with Sender-ID, requires email-address domain
> owners authorize the source of their email

At least we now have a complete list of traps and pitfalls for
that idea.  If all else fails we could "SSP" the Message-IDs,
or I'd try to understand your fresh "DKIM options" draft. <g>

                              Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Dec 2005 14:53:59 -0800

On Dec 22, 2005, at 12:06 PM, Frank Ellermann wrote:

> It could also work for news if we get the FWS canonicalization right.

Agreed.  The presents of the signature should not impose limitation  
upon what content (email-address) is carried.

>> Schemes related to the email-address such as S/MIME or OpenPGP are  
>> designed to support email-address limitations.
>
> Maybe they missed the point, mail without signature.  A simple way  
> to publish that all mails claiming to be from X are spam if they  
> don't have X's signature.  [ I'm just spamcop-ping 36 phishes  
> claiming to be from my bank, hilarious ]

If the MTA or MUA cached assurances (binding) found in messages  
indicating this message should always be signed, then the only  
additional lookup needed would be to confirm continuation of the  
assurance when such message is found lacking the signature.  The  
caching require to mitigate most abuse could be simply a list of  
domain names held within a local DNS zone.  Once recognition at the  
MUA becomes widely deployed, caching at the MTA would be redundant  
and not needed.

For SSP, there is a policy search walking up DNS label trees for  
nearly each and every email received, and will likely lead to  
coercion to increase the number of domains publishing records.  As an  
alternative, the recognition approach allows incremental deployment.   
For many domains, a closed-policy will be disruptive and yet an open- 
policy will likely damage their reputation.  The binding approach  
does not incur the overhead, risk reputations, or require coercion to  
mitigate policy overhead.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 22 Dec 2005 16:59:56 -0800

> They need to respect history more.

To follow the sausage-making analogy, DKIM has barely gotten past the 
stage of deciding whether or not to kill the animal first.  Now, I 
think, the argument is about whether to grind the meat.

Steve, it may be worth mentioning to your external consumpters that 
DomainKeys is useful NOW.  DKIM won't be deployed widely enough to be 
useful to senders until about a year after the IETF finishes with it.

And if DKIM isn't an easy replacement for DK, it may never be deployed 
widely at all.

Yay standards!  Can somebody pass the mustard?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 17:13:00 -0800

> And if DKIM isn't an easy replacement for DK, it may never be deployed 

gosh, what an interesting point.  one might almost think it would be 
good to restrict specification changes to those that are essential for 
dkim's success.

oops.  unreasonable suggestion.  all sorts of nasty (albeit ill-defined) 
implications.

d/

-- 

  Dave Crocker

---

From: Andrew Newton <[email-masked]>
Date: Thu, 22 Dec 2005 22:31:59 -0500

On Dec 22, 2005, at 7:59 PM, J.D. Falk wrote:

> DKIM won't be deployed widely enough to be useful to senders until  
> about a year after the IETF finishes with it.

That's a pretty interesting statement considering this argument is  
about backwards compatibility with the "wide deployment" of a  
specification that has been public for less than 6 months (draft- 
allman-dkim-base-00 has a publication date of July 9, 2005).

If anybody has an issue with the text Tony has suggested, it should  
be discussed.  Otherwise, I think this thread has reached the end its  
useful life.

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 21:11:39 -0800 (PST)

On Fri, 23 Dec 2005, Mark Delany wrote:

> On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
>
>> pressure on DNS infrastructure
>
> Unproved speculation. As you know, email, compared to HTTP and P2P
> (neither of which sought approval from the IETF) constitutes an
> increasingly tiny part of the Internet load these days. The serious
> pressure comes from applications that never came near the IETF.

That is not a proper comparison. DNS is a key protocol (not to be
confused with protocol "for keys" :) for almost all other L7 protocols
on the net. HTTP was just "another" protocol and its use would not have 
had much effect on say telnet or ftp (ok, for ftp it might as it began
to be used as replacement, but that is different matter). We have to be
a lot more careful what we choose to do with dns and I think it should
stay primarily as a protocol for "linking" domain names. to specific
data locations rather then becoming all-purpose database.

Another issue is that dns is not just client->server protocol where
impact of using it would only be limited to server that chose to
deploy dkim records and client that chose to check it.

My view is that there is enough uncertainty and that if load on [core]
protocol like dns can be minimized and moved into specific L7 protocol
like SMTP, that it should be done. And we do have easy enough way to
do it with DK-like system by using fingerprints.

> Unproved speculation. As you know, 512 is not a UDP limit it's a DNS
> implementation limit which was long ago removed by EDNS0 - an IETF
> standard.

Nevertheless for immediate future [at least 5 more years, probably 10]
512bytes is basically limit that dns records should fit in.

BTW - that case of adding EDNS extension to widely deployed system and
how slow long it takes to do is an example why adding additional key
authorization methods to DKIM would not be easy and why we should worry
about this issue right now.

> The other minor matter is that the Internet is already participating
> in a billion+ DK signed and verified emails per day - I've been
> watching, but as yet, no news at 11. At what point do you expect the
> pressure to be noticed?

The number of emails being signed and checked is actually the main
factor - especially for sites that constantly communicate with each 
other.

What would make a difference is large number of "small" domains that only
occasionally send emails but would have a signature on them requiring
checking dns and caching the public key (I predict that specialized 
optimized caching servers would be needed - in fact its somewhat in my 
area so I may even make good money if we all have this requirement ...) 
Also small mail servers that have to check all signed emails would see
these issues in even greater degree. What would also make a difference
is when users at the largest domains begin to demand to be able to use 
their own unique keys.

> William. I admire your interest in optimizing DNS load, but, as Knuth
> might ask, is it premature? If you think not, convince us otherwise.

Nothing is premature when it comes to dns. Once you make mistake its
difficult to fix (without impacting ongoing deployment) even if other
services are known to be impacted. As I said, it comes down to that we
do have other choices to putting large records in dns and they are 
basically close to being equivalent to public keys in dns, so we should
choose those. At the very least make them available as core supported 
authorization methods so in the future if problems are found, there would 
be a backup plan that does not require upgrade of every site software.

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 Dec 2005 01:53:27 -0500

> Apparently you expect the extensive, open group consensus process that 
> was pursued TWICE on this matter to have no import, but the last-minute, 
> vague whim of a few posters instead should hold sway.

Dave,

Unless you can cite an IETF BCP RFC that authorizes unchartered, 
self-appointed, ad hoc groups to dictate the terms of their charters, 
constrain the behavior of chartered IETF working groups, or overrule the 
decisions of IESG in chartering a group, please rest your case.

Keith