Subject: Re: [ietf-dkim] draft Errata on RFC 4871

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Feb 2009 01:40:17 -0800 (PST)

Serves me right for having this thing on "digest" mode all this time, and 
missing all the fun.  Apologies, therefore, if my reply/replies here break 
threaded viewers, and certainly covers a few points that have probably 
been resolved, but I'd like to put my opinion out there for-the-record 
even if it's late.

First, some specific replies:

On Mon Jan 26 04:22:17 PST 2009, Tony Hansen said:
> I strongly support working on a 4871bis >>and<< moving DKIMbase forward
> to Draft Standard as part of that.

+1, although it looks like we've got rough consensus already on that 
particular point anyway.

On Mon Jan 26 13:24:45 PST 2009, J.D. Falk said:
> Also, +1 to Suresh's suggestion of a use cases document.

Wouldn't this be appropriate for the deployment document?

On Mon Jan 26 09:06:08 PST 2009, SM said:
> In my opinion, the draft is more than an erratum.

I'm still fence-sitting on my opinion about this, having read the entire 
thread to date.  As an implementor I've always been interested in making 
available a vector of information about the signature, not just the value 
of "d=" or "i=" since there are lots of possible local policy decisions. 
The API we produced also allows the caller to obtain things like the value 
of "s=", "l=", canonicalizations used and other relevant parameters. 
Thus, changing from having a single identifier to many doesn't phase me 
much.

I'm also not swayed in terms of working group procedure to either side. 
On one hand, I believe an erratum should only be things like correction to 
ABNF or typographical errors, so the addition of this much text seems to 
exceed such boundaries.  On the other, the proposed changes merely 
formalize some concepts and attempt to provide clarity to the output 
question, rather than introducing anything that's truly new.

I suspect most working groups that feel such correction is needed just go 
directly to the "bis" concept.  But that's probably just weak precedent, 
not required procedure.

Forced to choose, I guess I would agree that this fits as an erratum, but 
not comfortably; I certainly agree that it's pushing some 
probably-unwritten boundaries.  Perhaps the IESG might do well to consider 
if this is really an issue and, if so, propose amended guidelines.

On Mon Jan 26 18:58:39 PST 2009, Tony Hansen said:
> I don't think this idea meets the criteria that the i= value represents 
> the
>
> 	Identity of the user or agent (e.g., a mailing list manager) on
> 	behalf of which this message is signed ...
> 
> My reading of this is that you can have a 1-to-1 mapping between the i=
> value and the user/agent's identity, and you can have an N-to-1 mapping,
> but you can't have a 1-to-N mapping. "good", "bad" and "suspect" do not
> represent the identity.

+1.  If there's some data the signer wishes to express about the message 
that's not an identity, it's a candidate for a new (as-yet-unpublished) 
DKIM tag.  This is safe; a verifier that knows about the unpublished tag 
can make use of it, and those that don't are required by RFC4871 to ignore 
it.  If the idea becomes popular, it's a candidate for inclusion in some 
"bis" draft.

I don't really like the later-proposed idea of overloading, using 
"i=@good.example.com", i.e. encoding the annotation as a (likely fake) 
subdomain of the signing domain.  We made the thing extensible, so let's 
extend it if there are good reasons to do so.  Jim Fenton also made 
remarks in support of this idea.

On Tue Jan 27 13:21:51 PST 2009, Jon Callas said:
> It's trivial to make a new header for the stable identifier and have
> that be in the list of headers signed.

Although many will squawk about yet-another-bloody-identity-header, and it 
would require some pretty thorough definition work, I'd support this.

On Tue Feb 10 12:22:13 PST 2009, Doug Otis wrote:
> When the i= value exactly matches an email-addresses contained within
> signed header fields, it is reasonable to assume this value is
> representative of this email-address.

-1.  I believe that has to be communicated explicitly out-of-band by the 
signer, and implementors of basic DKIM should not be encouraged to make 
such conclusions based on heuristics.

On Wed Jan 28 12:06:56 PST 2009, J.D. Falk wrote:
> That kind of signing would prevent using i= for social networking,
> because even if Grandma pays for the account (and thus the user_id 
> roughly identifies her), drunken Uncle Ernie lives in the basement and 
> sponges off her AOL subscription, and they'd both have the same i= 
> value.

Dude, I really need to party with your family.  I've learned so much about 
them from ietf-dkim.

=====

Now, for some general comments:

Overall, I agree with the need to clarify the d=/i= issue, although I have 
no operational experience which makes this urgent.  I therefore agree with 
the content of the -02 erratum draft.  I'm still looking over Eliot's 
proposal to see if it achieves the same goals in less text.

I don't agree that use of "opaque" is confusing, although I am experienced 
with data structures and in that context its use is quite appropriate. 
Someone else might not be.  If we are to presume the draft is mainly 
geared toward implementors (and I think that's reasonable), I don't think 
it needs to be changed.  We could bounce the text off a few uninvolved 
coders (or non-coder messaging geeks) to see if it makes their eyes cross 
or not.  But to cite Jim's specific example, "opaque" means 
"unintelligible", which is appropriate in this context; the verifier isn't 
supposed to be able to make sense of the local-part-bit of an "i=" value.

Whenever we come up with a way "i=user@domain" might be useful to certain 
signers or applications as an argument in favour of supporting such, we 
must also consider how the spec, when modified to lend that support, can 
be abused.  As with most other mail security work to date, there's very 
little a legitimate signer can do which a spammer or phisher can't do (or 
won't try).  I'm not sure this concept got due consideration earlier in 
these discussions.

I would support the addition of a new key or signature tag which is an 
indication by the signer to the verifier that the local-part-looking-bit 
is stable, thus asserting that it is safe to use for identifier-specific 
(e.g. user-specific) reputation assessments.  One could also add such a 
tag which indicates that the local-part-looking-bit is something 
authenticated with SMTP AUTH, or something that appears in the local user 
database, or similar.  There's nothing beneficial here to an attacker; it 
(presumably) takes a while to build up a positive reputation but not long 
to go from zero to something negative, so they don't stand to gain in the 
short term much by making such assertions.  I'd be happy to drive the WG 
editing of such a draft if there's rough consensus to do so.

I agree that DKIM saying the local-part-looking-bit of "i=" is opaque, and 
then ADSP (which is an add-on, as someone pointed out) attempting to 
assert value about it, isn't a contradiction.  A signer wishing to 
participate in ADSP is free to turn "i=" into a stable e-mail address so 
that it can match From: if that's what ADSP requires. In the same way, UDP 
defines a transport mechanism while DNS specifies the format of its 
payload.  That said, I wouldn't be adverse to adding some kind of notation 
to a "bis" draft that later specifications based on DKIM might attempt to 
impose semantics, and implementors should make themselves aware of those.

A few minor nits about the -02 draft:

1. Introduction
 	- contains a reference to RFC5871, which should be RFC4871

 	- change "to clearly define" to "to define clearly"

 	- change "and specifies and their relationship" to "and specifies
 	  their relationship"

9. RFC4871 Section 3.5 The DKIM-Signature Header Field
 	- change "for an introduction of a message" to "for the
 	  introduction of this message"

10. RFC4871 Section 3.5 The DKIM-Signature Header Field
 	- change "...to an individual user name within their domain"
 	  to "...to an individual user name within its domain"

12. RFC4871 Section 3.9 Relationship Between SDID and UAID
 	- change "Hence reliance on... " to "Hence, reliance on..."

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