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=(_at_)good(_dot_)example(_dot_)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(_at_)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