Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871-errata-00

From: Jim Fenton <[email-masked]>
Date: Thu, 29 Jan 2009 17:03:22 -0800

I have quite a few comments on the proposed erratum submitted by Dave
Crocker.  Detailed comments first, general comments below.

Detailed Comments:

1. Is this a working group draft?  The title would seem to imply that it
is but I don't remember that happening.

2. Section 1, paragraph 2: "a consumer of the validated signing domain"
is confusing:  "consumer" in particular.  DKIM doesn't say anything
about how the results would be used, so all DKIM really has is a signer
and a verifier (which is the term used throughout the spec, not
validator). "...a user of successful verification results" also sounds
too much like it's a human and not some other module that acts on the
result.

3. same paragraph: '"responsible" domain name' implies that the result
is the domain name (which I probably don't agree with, see below) and
the last line talks about "details about the name".  Details about the
domain name?  I'm not sure what details of a domain name are, unless
you're hinting at the use of a subdomain with a particular name.

4. Section 2:  Section 2.7 should come later to avoid forward
references.  Identity Assessor is a poor name for this module because
it's not assessing an identity (depending on your definition of
identity, the Verifier might be doing that) but rather something based
on the signing identity.  I'm not sure what it means by "optionally
consume the UAID".  Does that mean that it can ignore it if it is
provided?  I suppose, but DKIM-base specifies a protocol, not the API
that the verifier uses to communicate with something downstream.

5. Section 3: "identity claiming responsibility" -> "domain claiming
responsibility" since that's what the base spec says it does (4871
section 1).  I don't see how this is opaque unless you say that domain
names are opaque (which I'm not going to argue) but I find the word
"opaque" in this definition confusing.

6. Section 4: User Agent Identifier is a terrible name for this.  The
UAID is the value of the i= tag, it says later.  i= is defined as the
"Identity of the user or agent (e.g., a mailing list manager)..." but
nobody said anything about a user agent.  We already have the term
"signing identity" used in the specification, and it's quite clear what
it means.

[Aside:  Having hung out with some people in the identity community
since the publication of RFC 4871, the one terminology change I would
make is to change "signing identity" to "signing identifier" because the
i= value isn't an identity, it's a pointer to an identity...an identifier.]

7. Section 5 talks a lot about how the sender can put all sorts of
things into the i= value.  When we wrote the spec, there was a clear
sense that most signers wouldn't even assert a local-part in the i=
value, and unless they were doing parent domain signing (section 3.8),
probably didn't need to use i= at all.  That's simple and elegant. 
Instead, this section is emphasizing how signers can put all sorts of
things in the i= value if they want to.  What's the motivation for
overloading the i= value with this stuff?  If they want to say something
only significant to themselves (perhaps for abuse tracking), it's easy
to define another tag for that value.  If they want to give a hint to a
reputation service that might want to do something below the domain
level (this is of dubious benefit; we don't know enough about reputation
yet) they can define a tag for that in an extension to the DKIM spec. 
We didn't do that in DKIM-base because we didn't know enough about what
was needed (and I'm not sure we do yet).

8. Section 5:  First paragraph seems to read that, even if the i= tag is
in the signature that verifies correctly, it's OK for the verifier not
to communicate that to an assessor.  Since some assessors may depend on
this value, for interoperability reasons the value MUST be communicated
if present.

9. Section 6:  The old definition of d= seems much clearer.

10. Section 7:  The replacement with UAID loses a useful example and
implies it's always a User Agent.

Sections 8-11 just seem to be sprinkling the UAID and SDID acronyms
elsewhere into the text.

Section 13:  Good grief, are the authors corporations now?  What
happened to IETF being as organization of individuals?

Appendix A:  Was the reference to d= intended to be humorous?  Perhaps
you should have used SDID rather than d=.

=====

General comments:

Despite its intent to clarify RFC 4871, I find the new terminology at
best adds little (SDID) and sometimes adds new confusion to the document
(UAID).  It emphasizes uses of the protocol, particularly "creative"
ways to use the Signing Identity, that if they need to be described at
all, probably belong in the Operations document.  It also attempts to
partially specify the API between the Verifier and a downstream
Assessor, which is not the subject of the DKIM specification.

-1.

-Jim

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 30 Jan 2009 07:31:32 -0600

Jem,

Responding with my own own views, and expressed in a longer note than one might 
wish, but a thorough review warrants a thorough response...

> is but I don't remember that happening.

As you know, 10 of us worked on developing the draft.  That's a substantial 
percentage of active working group participants.  When we reached nearly 
unanimous agreement on it, I submitted it as an I-D, with it's current name.

A new I-D that uses a wg name must be approved by a wg chair.  Stephen approved it.

> too much like it's a human and not some other module that acts on the

It's certainly true that we need to be clear about the model and the language.

I chose "consumer" as per the common distributed processing vocabulary of 
producer/consumer.  Didn't use it consistently, but that's where it came from.

On reflection, "user" is indeed a very poor choice.  Client or consumer would be 
more typical distributed processing label choices.  Perhaps there are other choices?

I don't know of any problems with the word 'verifier' that was already in the 
spec, and should have continued its use, rather than validator.

Your view that DKIM doesn't have any input or output, other than siging and 
verifying is a much deeper disconnect.  I believe it represents a commonly help 
view but that that is the source of many problems in disucssing DKIM. Some years 
ago, Ned Freed highlighted the distinction quite nicely, but I can't find his 
original text.

My feeble reconstruction is that DKIM's job is to for one party to be tell 
another that the first is 'responsible' for a message. It does this by 
communicating an identifier in the message, so the consumer can make assessments 
based on that the identity of the producer. It declares the producer's 
responsibility.  To achieve this goal, DKIM uses authentication technology so 
that the consuming party can trust that the producer's use of the identifer was 
valid.  In other words, DKIM authenticates the carriage of an identifier, but 
all of the spiffy authentication technology turns out to be a distraction, when 
talking about DKIM's "purpose".

Indeed, this is approximately what the approved DKIM documents say...

      DKIM Signature specification, Introduction:  "permitting a signing domain 
to claim responsibility for the introduction of a message into the mail stream." 
The surrounding references to crypto, etc, are all in the service of this quoted 
goal.  Note that it does not mean much for the producer to claim responsibility 
if there is no consumer of that information.  Simply verifying the identifier 
can't be the goal.  Consuming it for further processing is the goal.

      DKIM Overview, Introduction:  "DKIM allows an organization to take 
responsibility for a message, in a way that can be validated by a recipient." 
Again, it does not mean much for one side to take responsibility (and 
communicate that fact via DKIM) if nothing on the other end uses the 
information.  Hence, the real purpose of DKIM is to give some identification 
information to that other end to use.  Hence, DKIM has real "output".

For the draft Deployment document that we are developing, I've suggested the 
following diagram, primarily derived from a conversation with Mike Adkins, of 
AOL, when he noted that the module that comes after verification is the real 
target of DKIM.

Personally, I've found that it greatly clarifies the systems view of DKIM's role:

   +------+------+                            +------+------+
   |   Author    |                            |  Recipient  |
   +------+------+                            +------+------+
          |                                          ^
          |                                          |
          |                                   +------+------+
          |                                -->|  Handling   |<--
          |                                -->|   Filter    |<--
          |                                   +-------------+
          |                                          ^
          V                                          |
   +-------------+  Responsible Identifier    +------+------+
   | Responsible |...........................>|  Identity   |
   |  Identity   |                            |  Assessor   |
   +------+------+                            +-------------+
          |                                         ^ ^
          V        DKIM Service                     | |
+-----------------------------------------------+  | |
| +------+------+              +-------------+  |  | |  +-------------+
| | Identifier  |              |  Identifier +--|--+ +--+ Assessment  |
| |   Signer    +------------->|  Validator  |  |       | Databases   |
| +-------------+              +-------------+  |       +-------------+
+-----------------------------------------------+

> you're hinting at the use of a subdomain with a particular name.

ack.

> 4. Section 2:  Section 2.7 should come later to avoid forward

ack.

> on the signing identity.  I'm not sure what it means by "optionally

The verifier confirms that the identifier is valid.  It performs no reputation 
or other "assessment" of the person, role or organization that owns that 
identifier.  Assessment is a nicely neutral term, without the kind of baggage 
that 'reputation' or some other words carry.

So, there clearly is a module that comes after verification and that module is 
postulated as using the identifier for some sort of analysis (assessment)

> provided? 

That's my interpretation of that text, yes.

 >          I suppose, but DKIM-base specifies a protocol, not the API

I think you are confusing protocol functionality with systems implementation.

Protocols have payload.  They deliver stuff.  The domain name is DKIM's payload. 
An implementation has an API. The Errata draft does not talk about an API.  It 
talks about output.

It is common and, I believe, absolutely essential, to view any particular 
protocol as having specific inputs and outputs, and to distinguish this from the 
stuff that is done inside the protocol, in order to take in the input and give 
out the output.

> responsibility" since that's what the base spec says it does (4871

Yeah, that's an error in the base spec that needs fixing.

As for identity, versus identifier, versus...

Overall, the security community uses these terms inconsistently, IMO.  It 
probably does not matter which exact words we use, as long as we define them 
very carefully and use them very consistently.  That suggests the need for some 
more Terminology definitions.

The rationale for the words used in the Errata derive from an interaction I had 
a couple of years ago, with an identity-related security expert who I hold in 
high regard who came up.  After a meeting he essentially took me out behind a 
shed and politely whacked me up the side of the head, for messing up concepts 
and terminology.  I've tried to be very careful with the words ever since...

There is a person, role or organization that does stuff, such as creating a 
message, or submitting a message or relaying a message, or performs some other 
sort of handling action with a message, for which they are willing to take some 
responsibility.  There needs to be a term for "person, role or organization" and 
the document uses "identity" for that.

Identity is, therefore, a reference to something non-technical that uses 
technical stuff like email and DKIM.  With DKIM, the identity needs to affix a 
label that refers to the identity.  The document uses the term identifier for 
this purpose.  Hence "identity" is an abstract thing and identifier is a 
reference to the thing.

If you send me one piece of mail, signed Jim Fention and another signed James 
Fenton, I evaluate them under a single body of knowledge, namely the identity 
that is use.  The two different strings you used are different identifiers that 
refer to the same identity.

A domain name is an identifier.  For DKIM it is a label that refers back to the 
entity taking responsibility.  Given that a domain name is nothing but a bunch 
of bits, it isn't possible for it to "take responsibility".  The owner of the 
domain name takes the responsibility.  The owner is a person, role or 
organization.  In other words, an identity.

> "opaque" in this definition confusing.

Opaque means that the DKIM specification imparts no semantics for two domain 
names that might appear to a human to be related.  That a human might see a 
possible relationship and that they might program their software to take 
advantage of it is entirely reasonable, but it is outside the spec.

By way of similar example, the message you sent had some Received header fields 
with a number of domain names, including:

      dhcp-171-71-97-221.cisco.com
      xfe-sjc-211.amer.cisco.com
      sj-core-1.cisco.com

While a human can see all sorts of stuff to interpret, there, the semantics are 
simply that each string can be fed into the DNS and should return one or more 
RR's.  There is no 'relationship' from one of these names to the next, in terms 
of Received field semantics.

One of the various sources of confusion about DKIM comes from individuals making 
assumptions about how "related" domain names will be treated by receivers.  For 
the DKIM spec, there is no relationship.  Anything a receiver does beyond that 
is just that:  beyond the spec.

> "signing identity" used in the specification, and it's quite clear what

The term "signing identity" is used ambiguously in the base spec.  The goal for 
the Errata draft was to substitute two new terms that did not (yet) have to 
carry the baggage of that confusion.

I'm pretty sure no one is in love with the two acronyms we produced but, as you 
know, it was produced through a group discussion.

> i= value isn't an identity, it's a pointer to an identity...an identifier.]

I completely agree.  But that leads to the problem of appearing to claim that an 
identifier takes responsibility.

> probably didn't need to use i= at all.  

Whereas my own assessment of that history is that there were *individuals* who 
each tended to have their own, personally clear sense of things, but that there 
was very little clarity amongst the working group.  More importantly, a clear 
sense when predicting a future does not make the prediction reasonable to make 
or correct, especially when the prediction is stochastic, with language like 
"most", and most especially when the spec gives no clear or strong direction 
about usage.

In any event, what we have seen quite a bit since the spec was published is 
confusion and that's what prompted the Errata effort.

 >       That's simple and elegant.
> overloading the i= value with this stuff?  

As written, the specification allows it.  Over the history of protocol 
specifications it turns out to be quite common that users of a protocol exercise 
whatever flexibility the specification permits (and usual more than that.)

>                 If they want to say something

Your assessment of dependence takes a particular role of i= as a given, when 
it's been clear from recent discussion that it's role isn't clear.  And clearing 
that up is one of the goals of the Errata draft.

As for the option not to pass the value, the implication of your view is that 
DKIM's output is actually two different identifiers, rather than the one that is 
stated in the Introduction.

> implies it's always a User Agent.

What example is lost?

> happened to IETF being as organization of individuals?

Wow.  Hadn't seen that.  Gosh, those companies sure are sneaky, what with making 
me type that contact info into the draft the wrong way...

> you should have used SDID rather than d=.

It was meant to be humorous.

-- 

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

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 30 Jan 2009 19:38:37 +0530

> more typical distributed processing label choices.  Perhaps there are other choices?

"customer" seems to fit the bill

> ago, Ned Freed highlighted the distinction quite nicely, but I can't find his

If it helps clarify the situation a bit, I came across this
interesting article - clarifies "identity", "authentication" and
"authorization"

http://technet.microsoft.com/en-us/library/cc512578.aspx
It's Me, and Here's My Proof: Why Identity and Authentication Must
Remain Distinct
By Steve Riley
Senior Security Strategist
Security Technology Unit
Microsoft Corporation

May I suggest that those 3 terms be used here, extensively?   There's
a clear distinction between the three, and several parallels between
the security / PKI field, where identity management is a concern, to
this field.

srs

---

From: Michael Adkins <[email-masked]>
Date: Fri, 30 Jan 2009 11:49:05 -0500

> the security / PKI field, where identity management is a concern, to

This article uses the term 'identifier' without offering a definition. 
It seems to use 'identifier' to mean the same thing as 'identity', and 
both those words only refer to the names of things, not actual things. 
Actual things are referred to as 'principals'. I suppose that could be 
clearer since two words that sounds similar are referring to the same 
concept, but I don't know whether 'principal' is intuitive enough or not.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 30 Jan 2009 23:36:05 +0530

On Fri, Jan 30, 2009 at 10:19 PM, Michael Adkins
<[email-masked]> wrote:
> This article uses the term 'identifier' without offering a definition. It
> seems to use 'identifier' to mean the same thing as 'identity', and both
> those words only refer to the names of things, not actual things. Actual
> things are referred to as 'principals'. I suppose that could be clearer
> since two words that sounds similar are referring to the same concept, but I
> don't know whether 'principal' is intuitive enough or not.

A few concepts which seem to be drawn from other fields of study I guess?

Identifier is a pointer to an identity is how I understood it.

Identifier =  "Something that identifies or names".  Programming
concept, that .. http://en.wikipedia.org/wiki/Identifier

Identity = "An identity is an equality that remains true regardless of
the values of any variables that appear within it" from math - what
they denote by a triple bar (≡) rather than the double bar equal to
sign (=).  An identity might have several identifiers mapping to it, I
dare say?

Principal is a legal concept - someone who authorises an agent to act
on his behalf to create a legal relationship with a third party.  I
can see where a client who commissions an ESP to send email on their
behalf would be the principal. And the agent / executor would be the
d= responsible for actually sending out the email.

--srs

---

From: "Olivier MJ Crepin-Leblond" <[email-masked]>
Date: Fri, 30 Jan 2009 22:55:09 +0100

"Dave CROCKER" <[email-masked]> wrote:

> advantage of it is entirely reasonable, but it is outside the spec.

I too was confused by the use of the word "opaque".

A dictionary definition of the word opaque shows:

1.a) Imprenetrable by light; neither transparent nor translucent
b) Not reflecting light
2. Imprenetrable by a form of radiant energy other than visible light
3.a) So obscure as to be unintelligible
b) obtuse of mind; dense.

Whilst you might consider me to be 3.b) for asking this question, 
which
one of the definitions of opaque is the one used in the RFC?

Would the word "arbitrary" not be more suited for the meaning 
researched?

Not wanting to beat a dead horse - if this has already been flogged, 
please forgive me.

Warm regards,

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: John Levine <[email-masked]>
Date: 31 Jan 2009 00:07:11 -0000

>I too was confused by the use of the word "opaque".

It's a standard term in data structures, for a thing which A hands to B,
and B can only use to hand back to A, not peek inside it.

>Not wanting to beat a dead horse - if this has already been flogged, 

You're forgiven.  If you ever come up to Cambridge, we can arrange in
person forgiveness, preferably with beer.

R's,
John