Subject: [ietf-dkim] summarizing my understanding of the errata discussion & a proposal

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Feb 2009 08:00:25 +0100

Tony, Dave, and John,

Thanks for your patient explanations.  Particularly you, Dave.  You did 
quite a number of rounds with me in private.  To summarize what I 
understand (or misunderstand), the fundamental issue with this erratum 
is that the text surrounding i= in RFC 4741 does not sufficiently warn 
people as to the limits of its use.  Dave's message on January 9th 
probably stated it best as follows:

> The fact that there are serious, knowledgeable folk who declare it is 
> the d= tag
> and other, equally serious and knowledgeable folk who declare that it 
> is the i=
> tag, and that there are substantial numbers of each means that we have 
> a real
> and basic problem:
>
>            The community does not currently have consensus about
>            where to find the one value that is DKIM's output!

The concern seems to arise out of insufficient sternness in the 
informational note for i=:
>        INFORMATIVE DISCUSSION: This document does not require the value
>            of the "i=" tag to match the identity in any message header
>            fields.  This is considered to be a verifier policy issue.
>            Constraints between the value of the "i=" tag and other
>            identities in other header fields seek to apply basic
>            authentication into the semantics of trust associated with a
>            role such as content author.  Trust is a broad and complex
>            topic and trust mechanisms are subject to highly creative
>            attacks.  The real-world efficacy of any but the most basic
>            bindings between the "i=" value and other identities is not
>            well established, nor is its vulnerability to subversion by
>            an attacker.  Hence reliance on the use of these options
>            should be strictly limited.  In particular, it is not at all
>            clear to what extent a typical end-user recipient can rely on
>            any assurances that might be made by successful use of the
>            "i=" options.

Here, the consumer of this information, the verifier, is warned against 
making use of i=.  However, what we are now saying is that practical 
deployment experience requires a stronger warning; that absent 
additional information from the signer that is not exposed by this 
specification, verifiers SHOULD NOT rely on i= as any sort of identity, 
because the value may not be present or stable.

My two questions:

   1. Why not just say that in the erratum?  It has the advantage of
      being very concise, requiring no additional terminology, and even
      better, no additional FLAs.  It also clearly meets the parameters
      for an erratum.
   2. Is the above statement actually true?  Do we have practical
      experience that shows that i= is either unstable or unused?  Can
      someone talk to that point?

One remaining point of discussion:

While the confusion arises between d= and i=, what verifiers do with a 
valid signed message is still up to them.  They could take input from 
various header fields if they wish (and some assuredly do and will).

Comments?

Regards,

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 03 Feb 2009 23:57:40 -0800

> various header fields if they wish (and some assuredly do and will).

Correct.

Just as they can ignore the Reply-To, use whatever TCP congestion control 
algorithm, or alternate route ranking they want, no matter what BGP tells them.

No problem with interoperability for any of those choices, either.

Bottom line:  A protocol is about defining specific and constrained semantics 
that are shared between both sides of an exchange.  The fact that any 
participant is free to deviate from that protocol is always true.  Hence there 
is no 'information' in pointing it out, unless you want to start adding it to 
every protocol spec.  Sort of like other RFC boilerplate, it won't be all that 
helpful, except for making the document bigger.

d/
-- 

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 04 Feb 2009 10:15:16 -0000

> because the value may not be present or stable.

No, SHOULD NOT is too strong. Normally, that would indeed be the case, but  
in specific cases the Assessor (not the Verifier) might have information,  
obtained by some out-of-band means, what that particular i= meant, and be  
able to act accordingly. Otherwise (and maybe always), assuming the d=  
matched satisfactorily, the i= should just be passed on to the end user  
who might make some sense out of it (e.g. Aunt Tillie vs Uncle George).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Feb 2009 09:32:16 -0800

On Feb 4, 2009, at 2:15 AM, Charles Lindsey wrote:

>> Here, the consumer of this information, the verifier, is warned  
>> against making use of i=.  However, what we are now saying is that  
>> practical deployment experience requires a stronger warning; that  
>> absent additional information from the signer that is not exposed  
>> by this specification, verifiers SHOULD NOT rely on i= as any sort  
>> of identity, because the value may not be present or stable.
>
> No, SHOULD NOT is too strong. Normally, that would indeed be the  
> case, but in specific cases the Assessor (not the Verifier) might  
> have information, obtained by some out-of-band means, what that  
> particular i= meant, and be able to act accordingly. Otherwise (and  
> maybe always), assuming the d= matched satisfactorily, the i= should  
> just be passed on to the end user   who might make some sense out of  
> it (e.g. Aunt Tillie vs Uncle George).

Charles is correct.  Currently RFC 4871 states the signer can use this  
optional value to indicate on whose behalf the signature is added.   
The fact that the identity contained within the i= value may be  
understood only by the signer would be a secondary issue that does not  
detract from an ability to mitigate abuse from signer recognized, but  
otherwise anonymous, sources.  However, when the i= identity is  
understood to represent an email-address contained within the message,  
such Aunt_Tillie@ or Uncle_George@, then the "SHOULD NOT RELY on i="  
admonishment would be in direct conflict with the existing RFC.  The  
i= SHOULD always indicate in some undefined manner, on whose behalf  
the signature was added whenever this value is added to the  
signature.  The identity represented by the i= value may or may not be  
opaque to the recipient.

The use of fictitious subdomains within the i= value would be a simple  
way to ensure there are no name collisions.  For example,  i=[email-masked] 
  could be used when the i= value represents a Radius account number.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Feb 2009 19:40:14 +0100

I responded to Charles privately, but there seems to be more general 
confusion (and perhaps some on my part):

On 2/4/09 11:15 AM, Charles Lindsey wrote:
> On Wed, 04 Feb 2009 07:00:25 -0000, Eliot Lear<[email-masked]>  wrote:
>
>    
>> absent additional information from the signer that is not exposed by this

First, I stuck to terminology that was in RFC 4871 intentionally, with 
an eye toward keeping the errata simple.

Second, there is a predicate prior to the SHOULD NOT statement which is 
important.  However, it has been lost by more than one person indicating 
lack of clarity.  Let's try this again:

    The contents of i= may not be a stable, and hence may not be
    suitable for programmatic consumption on their own.  As such, it is
    NOT RECOMMENDED that verifiers consume the contents of i= without
    additional external inputs that are provided by the sender.

Doug Otis cites the case I wonder as to whether it exists.  One could 
envision all sorts of  things going on within the LHS of the @, like a 
encrypted username with a nonce.  I can't say whether anybody actually 
does that or wants to do that.

Eliot

---

From: John Levine <[email-masked]>
Date: 4 Feb 2009 19:31:33 -0000

>because the value may not be present or stable.

That's basically it.

>      experience that shows that i= is either unstable or unused?

In my limited experience it seems to be reasonably stable when it's
used, but it doesn't reliably match other fields, and there are
significant signers that don't use it.  Peeking at my inbox:

gmail  no i= (many messages)
Cisco  i=from address
my system  i= stable but doesn't match any address
linx.net no i=
sendmail two signatures, no i= in either

So in this admittedly statistically invalid sample, most of the DKIM
signatures had no i=, only Cisco had a non-opaque one.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Feb 2009 11:48:23 -0800

On Feb 4, 2009, at 10:40 AM, Eliot Lear wrote:
>
> Doug Otis cites the case I wonder as to whether it exists.  One  
> could envision all sorts of  things going on within the LHS of the  
> @, like a encrypted username with a nonce.  I can't say whether  
> anybody actually does that or wants to do that.

Imagine that in the near future, DKIM becomes a major factor in  
determining message acceptance.  This might occur when there are too  
many IPv6 address to utilize block-lists that are too large to  
economically track and publish.  No only might the list size become  
problematic, evidence must also be retained for each listing.  An  
inability to publish block-lists will then mean acceptance is likely  
to be based upon white-listed IP address of SMTP clients.  For  
messages from SMTP clients outside the white-lists, something like  
DKIM might play a greater role. When it does, it becomes important to  
protect DKIM signatures from being abused.

A domain not having any problem with their accounts will not need to  
worry about the stability of the i= value.  For those that find their  
signatures abused, there will be a limit as to the number of i=  
entries that can be tracked.  Once this i= limit is exceeded, use of  
the domain's DKIM signature as a basis for acceptance will have become  
impractical.  On the other hand, when the i= value is stable, abuse  
will be easier to handle, as it should not increase much beyond the  
total number of problematic accounts.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 Feb 2009 15:09:35 -0500

>    additional external inputs that are provided by the sender.

If you excluding the idea of syntax checking, then fine.  But 
according to RFC 4871, there was always the possibility of syntax 
checking that can be performed and SHOULD be perform for protocol 
consistency, and WILL be perform by our DKIM verification if that ever 
comes to happen.

The problem as I see is that we are getting lost with the multiple 
undefined application possibilities of DKIM, i.e, the presentation 
part mostly.

It is important that once SMTP systems (en masse) begin to check for 
the new DKIM level messages, that protocol expectations are honored 
consistently across the board, including syntax checking.

The i= is opaque in format, but transparent to the verification 
process, meaning, it is passthru just like the rest of the 2822 
headers. The d= has its specific purpose, and the i= has a specific 
syntax, if used, that must be DKIM 4871 compliant.

Message Integrity is not just in the repeatability of the message 
hash, but in its complete signature as well. Failure detection is a 
strength of the protocol because it helps raise the "email" bar above 
and beyond standard 821/2821/5321 requirements. It is what will help 
protect signing domains more so than verified signatures that have 
little payoff without augmented undefined black/white/grey listing or 
reputation technology. However, DKIM doesn't not "Required Batteries" 
to fully function. When receivers detect failure, IMO, it is thee 
major part of the payoff realization and benefit of the both domains, 
signers and receivers.

So I think we need to separate the heuristic ideas from the 
deterministic protocol ideas.  The i=, if used, has a specific format 
it must follow, but shouldn't be used for anything else.  I believe 
that is what this Errata is trying to make sure it is understood.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: SM <[email-masked]>
Date: Wed, 04 Feb 2009 14:15:57 -0800

At 23:00 03-02-2009, Eliot Lear wrote:
>Here, the consumer of this information, the 
>verifier, is warned against making use of 
>i=.Â  However, what we are now saying is that 
>practical deployment experience requires a 
>stronger warning; that absent additional 
>information from the signer that is not exposed 
>by this specification, verifiers SHOULD NOT rely 
>on i= as any sort of identity, because the value may not be present or stable.

The warning is about requiring the "i=" tag to 
match any header fields.  More comments below.

>    * Is the above statement actually true?Â  Do 
> we have practical experience that shows that i= 
> is either unstable or unused?Â  Can someone talk to that point?
The catch is that i= may appear unused because of 
the way it defaults to the d= tag.

>While the confusion arises between d= and i=, 
>what verifiers do with a valid signed message is 
>still up to them.Â  They could take input from 

Some verifiers may do that but there isn't 
anything we can do about it except to put a note.

The following contains text from RFC 4871.

The d= tag must be the same as or a parent domain 
of the "i=" tag.  Restrictions can be enforced on 
the i= tag with the g= tag or the t= flag.

   "In some circumstances, it is desirable for a domain to apply a
    signature on behalf of any of its subdomains without the need to
    maintain separate selectors (key records) in each subdomain."

In practical terms, I can sign for a subdomain 
without further DNS changes.  I noticed a few 
sub-domains from a (biased) sample of over two thousand domain identifiers.

   "If the DKIM-Signature header field does not contain the "i=" tag, the
    verifier MUST behave as though the value of that tag were "@d", where
    "d" is the value from the "d=" tag"

That's one of the uses of the domain in the "i=" 
as we can use the value from "d=" when the "i=" 
is absent in the DKIM-Signature header.  The 
question is which signing domain identifier 
should we use.  RFC 4871 says that it should be 
the domain value from "i=".  There are 
specifications from this WG and outside it that are built upon that.

There is a well-known email service provider that 
is not interpreting the "i=" correctly.  Instead, 
they use the domain part of "d=" as the "i=" 
domain value.  I'm not aware of other implementations with that problem.

Technically, there is nothing that stop us from having:

   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
          c=simple/simple; q=dns/txt; i=@x.example.com;
          h=Received : From : To : Subject : Date : Message-ID;
          bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
          b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
            4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
            KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
            4bmp/YzhwvcubU4=;
   Received: from client1.football.example.com  [192.0.2.1]
          by submitserver.example.com with SUBMISSION;
          Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <[email-masked]>

where x.example.com is an identifier used to 
aggregate the Joe SixPack group of users.  We 
could also pass such information as:

   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
          c=simple/simple; q=dns/txt; i=[email-masked];
          h=Received : From : To : Subject : Date : Message-ID;
          bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
          b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
            4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
            KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
            4bmp/YzhwvcubU4=;
   Received: from client1.football.example.com  [192.0.2.1]
          by submitserver.example.com with SUBMISSION;
          Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <[email-masked]>

where "clue" in used to aggregate the Joe SixPack 
group of users.  But then it doesn't fit the description of user or agent.

For assessment purposes, some vendors may find it 
easier to use example.com as the identifier from 
the two above examples.  Note that there isn't 
any tie to information available through Whois as 
the domain could have been "podunk.ca.us" or some 
domain without any valid registrant information.

The domain value is generally useful for feedback 
loops, for organizations with a homogenous 
user-base, if the receiver will only accept DKIM 
signed messages or by agreement between the 
sender and receiver.  For what it's worth, there 
are some gov.uk messages which include an i= tag 
where the Local-part matches the author of the 
message; the is an email address match.

At 10:58 04-02-2009, Dave CROCKER wrote:
>Opaque does not mean that the signer had no 
>intent behind the choices they made in doing the 
>encoding.  And in the case of domain name 
>strings, it doesn't mean that the recipient side 
>can't know it's a domain name.  It means that 
>they cannot know the scheme the signer used for choosing sub-domain names.

 From previous discussions, it has been mentioned 
that DNS does not have a feature to determine 
administrative boundaries.  In the dot-com world, 
the sub-domain may seem obvious.

>There is a difference between being able to use 
>the d= signing domain versus having deep 
>knowledge about the underlying intent behind encoding choices for it.

Agreed.

>You know my name is David.  You do not know why 
>my parents chose that name, and it doesn't 
>matter for your use of it as an identifier.

If you use that name for signing, then I can use 
it as an identifier for you.  I do not need to 
know why you are using that name.  The argument 
against i= seems to be that it should not be used 
as we don't know why that name is being used.

The WG could, as part of some future work, 
consider obsoleting the "i=" tag if it believes 
that it is a source of confusion when identifying 
which domain value is appropriate or if it 
believes that it is better to have one instead of 
two more identifiers for Internet Mail.

Regards,
-sm

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 05 Feb 2009 11:36:16 -0000

> an eye toward keeping the errata simple.

Yes, but we are currently discussing Dave's errata, which carefully  
distinguishes between the Verifier, which does the purely machanical  
checking of the signature for validity, and the Assessor which decides  
what action to take on the result.
> lack of clarity.  Let's try this again:

Yes, I take the point about your predicate. My main target was Dave's  
remark (Mon 02 Feb 2009 19:42:44 GMT)
     Since the new consensus appears to be that i= has semantics that are
     entirely undefined, it does not seem possible that the wg would advise
     showing it to an end user.
But I now see that such wording does not appear in his actual latest  
draft, and the current thread seems happy that the end user should indeed  
be given the opportunity to differentiate between Aunt Tillie and Uncle  
George in cases where the Assessor had insufficient information to utilize  
that inormation itself.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Feb 2009 07:47:38 -0800

On Feb 5, 2009, at 3:36 AM, Charles Lindsey wrote:
>>
>> First, I stuck to terminology that was in RFC 4871 intentionally,  
>> with an eye toward keeping the errata simple.
>
> checking of the signature for validity, and the Assessor which  
> decides  what action to take on the result.

This new function called the Identity Assessor for DKIM would  
presumably be focused on identities.  For DKIM, it might determine  
which portion of an email-address gets highlighted.

When the i= field _exactly_ matches with an email-address contained  
within a signed header field, this entire email-address could be  
safely highlighted.

The statement within Section 9 of the Errata prevents being able to  
provide this feature.
,---
Hence, DKIM delivers to receive-side Identity Assessors responsible  
Identifiers that are individual, opaque values. Their sub-structures  
and particular semantics are not publicly defined and, therefore,  
cannot be assumed by an Identity Assessor.
'---

Statements that imply the i= value is always OPAQUE prevents its  
utilization for highlighting purposes with respect to identity  
assurances, even when there is an exact match and this value could be  
said to not be opaque. This also seems to conflict with the defined  
use of the i= value as representing on whose behalf the signature was  
added.  There should be an exception spelled out for exact matches.

Such as:

Hence, DKIM delivers to receive-side Identity Assessors responsible  
Identifiers that are individual, where unless the AUID exactly matches  
a signed header's email-address, is to be considered an opaque value.   
Being opaque means the AUID sub-structures, and particular semantics,  
are not publicly defined and, therefore, cannot be assumed by an  
Identity Assessor.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Thu, 5 Feb 2009 08:08:57 -0800

> added.  There should be an exception spelled out for exact matches.

Forgive me for this short rant and applying a riding crop to this  
horse, but when you say:

	"Statements that imply the i= value is always OPAQUE
	prevents..."

You are correct.

However, the fact that you do not wish it to be opaque does not make  
it transparent. It is opaque. It is not in "... conflict with the  
defined use..." because it *IS* the defined use. It is not your  
*desired* use, but it is the defined use.

Why is it so hard for you to just write a followon RFC to DKIM that  
has an  Identity Accessor or whatever you want, that you stick in some  
header and sign *that*, rather than continuing to insist that i= is  
what it is not?

For all the effort we keep spending declaring that the sky is green,  
we can just go get some nice tinted lenses.

I *support* creating a header that is what you want, but really,  
that's not what is in DKIM-base. Just write up an I-D defining the  
header you want!

	Jon

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Feb 2009 11:36:11 -0500

> within a signed header field, this entire email-address could be  

And what if it doesn't match, do you color it Grey? Not color it all?

What happens after inevitable failure is par course, no highlights. 
Should the user be worry? Of eventually ignore it, thus putting the 
user an unsafe harbor with those that are highlighted?

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Feb 2009 17:27:17 -0800

Eliot Lear wrote:

My two questions:

1. Why not just say that in the erratum?  It has the
advantage of being very concise, requiring no additional terminology,
and even better, no additional FLAs.  It also clearly meets the
parameters for an erratum.

I agree with the general spirit behind clarifying the use of i= in this
way.  I'm not sure I'd word it quite that way, but we can cross that
bridge later.

2. Is the
above statement actually true?  Do we have practical
experience that shows that i= is either unstable or unused?  Can
someone talk to that point?

I had expected that i= would receive little use.  While it's true that
Cisco happens to set i= to the From address, it doesn't really need to
do that.  I'm running dkim-milter at home and it doesn't (at least as I
have it configured) include an i= tag.  From a DKIM protocol
standpoint, there's only one situation where one MUST include i=, and
that's when the g= tag in the signature is more specific than '*'.

While ADSP does match against i= if it's there, the intent is primarily
to prevent a user of a (g=) restricted key from asserting an Author
Signature for addresses they're not authorized.  For that reason, Doug
Otis had suggested that we match the local-part of From against the g=
of the key rather than the i= of the signature, but there was no
consensus for that.

Comments?

I also think that the output of DKIM may be more than i= and/or d=.  We
made sure that DKIM was extensible; there could very easily be other
tag/value pairs that are invented in the future and that communicating
a "single Responsible Identifier" is a false premise.  There have been
lots of suggestions for additional tags:  at one point someone
suggested a tag indicating a transactional message, and the stable
opaque identifier thing could easily be another tag.  I'm not saying
that these are necessarily good ideas, but that there could easily be
other information in the signature that's useful to an assessor, if
it's present.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Feb 2009 19:20:45 -0800

>       better, no additional FLAs.  It also clearly meets the parameters

It is common for Errata to provide precise corrections.  That means supplying 
the exact text that needs to be changed.  While a generic "warning" is 
comforting, it is not precise.  For example, it requires an implementor to take 
the general warning and try to guess what aspects of the original specification 
have been changed.  Guess = non-interoperable.

 > various header fields if they wish (and some assuredly do and will).

Anyone can do anything.  That's always true, and so it's not an observation that 
helps a protocol specification be understood.

Stated differently:  Within a protocol specification, participants may NOT do 
whatever they want.  Once they choose to participate, they must follow the spec.

Verification is a very precise and mechanical process.  Supplying a verified 
identifier, as the output of verification, is the stated purpose of DKIM.  That, 
too, is a mundane and mechanical task, as long as the spec is clear about what 
identifier to supply.

How the identifier is then used is entirely outside the spec and, indeed it is 
here that folks do all sorts of things.

Jim Fenton wrote:
> tag/value pairs that are invented in the future and that communicating a 
> "single Responsible Identifier" is a false premise.  

1. Anything is possible in the future.  The assertion is about the present.  You 
do not appear to be saying that DKIM has other output now.

2. Single Responsible Identifier is not a premise, it's the explicitly stated 
purpose of DKIM, as quoted carefully in the Errata draft.  If you believe DKIM 
has other other goals and/or functions, where are they documented?

 >  There have been
> lots of suggestions for additional tags:  at one point someone suggested 
> a tag indicating a transactional message, and the stable opaque 
> identifier thing could easily be another tag.  I'm not saying that these 
> are necessarily good ideas, but that there could easily be other 
> information in the signature that's useful to an assessor, if it's present.

I'm not understanding how this is relevant to the current effort at resolving 
ambiguities about d=/i=?

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Feb 2009 13:21:45 +0100

Dave,

On 2/6/09 4:20 AM, Dave CROCKER wrote:
> comforting, it is not precise.

While I am very much amenable to a different set of text, I do not 
accept your characterization of the above text as a generic warning.  
The warning is actually quite specific.  It says that the value of i= 
may not be stable and it may not be present.  The guidance cannot be 
more specific because how the output of DKIM is used was classed out of 
scope by the working group.  In this respect, the value of i= is, hence, 
no different than, say, a signed header that may or may not be present.

And so I believe we are now debating SHOULD NOT versus MUST NOT, and I 
would accept that as well.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 Feb 2009 05:00:13 -0800

Eliot Lear wrote:
> The warning is actually quite specific. 

RFC4871 is a body of specific text.  Either one publishes replacements for its 
text or one publishes a rule that can be used for replacing text.  The current 
Errata draft does the former.  You want to do the latter.

The latter invites one reader to apply the rule differently than another reader. 
  The former does not.

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Feb 2009 15:15:09 +0100

On 2/6/09 2:00 PM, Dave CROCKER wrote:
> RFC4871 is a body of specific text.  Either one publishes replacements 
> for its text or one publishes a rule that can be used for replacing 
> text.  The current Errata draft does the former.  You want to do the 
> latter.
>
> The latter invites one reader to apply the rule differently than 
> another reader.  The former does not.

If what you would like is very specific text to be excised in exchange 
for the text I have proposed, I would be happy to go that far.  I 
thought it had been obvious.  However, I disagree with your conclusion.  
Errata in general provide for that invitation simply on the basis that 
they're not generally read.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Feb 2009 10:56:18 -0800

On Feb 5, 2009, at 8:08 AM, Jon Callas wrote:

>> assurances, even when there is an exact match and this value could  
>> be said to not be opaque. This also seems to conflict with the  
>> defined use of the i= value as representing on whose behalf the  
>> signature was added.  There should be an exception spelled out for  
>> exact matches.
>
> 	"Statements that imply the i= value is always OPAQUE prevents..."
>
> You are correct.
>

Disagree.

Per RFC 4871:
.---
  i=  Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;   
OPTIONAL, default is an empty Local-part followed by an "@" followed  
by the domain from the "d=" tag).  The syntax is a standard email  
address where the Local-part MAY be omitted.  The domain part of the  
address MUST be the same as or a subdomain of the value of the "d=" tag.
'---

When an i= value does not match with any identity within the message,  
only then should the i= value be considered opaque.

However, when the i= and the d= values _exactly_ match against an  
email-address within a _signed_ header, there is _no_ basis to assume  
a signing domain uses two separate and colliding namespaces within  
their messages.  Where is this occurring?  If it is, there should be a  
warning against such ill considered use of colliding namespace.  Why  
add extra knobs where none are reasonably required?

> has an  Identity Accessor or whatever you want, that you stick in  
> some header and sign *that*, rather than continuing to insist that  
> i= is what it is not?

Why would such an effort be required?  RFC 4871 has already made  
provisions for this use.  This Errata draft is not really an errata  
since it dramatically changes RFC 4871 definitions that appear correct  
as written.

It is not clear what problem is addressed by the assertions that there  
might be two separate and colliding namespaces used by a signing domain.

In addition, since the goal of the DKIM was to establish the domain,  
why describe the domain within the d= value as being opaque???

When a message is purportedly from an address within "example.com",  
why would it be reasonable to assume a signature added to this message  
where "example.com" provided public keys verifying the message is  
somehow to be viewed as opaque.  These definitions require an  
exception.  When it is not possible to associate domains, especially  
the _same_ domain within their signed message, the value of DKIM will  
have been seriously undermined.  When is it reasonable to assume there  
are separate and colliding domain namespaces?

> we can just go get some nice tinted lenses.

What problem do you see this over-extended opaque assertion solving,  
especially when it creates a problem where none had existed.

> that's not what is in DKIM-base. Just write up an I-D defining the  

On the other hand, by not changing these RFC 4871 definitions, there  
would not be a need to add new headers or additional signature tags.   
Don't change these RFC 4871 definitions.

-Doug

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Feb 2009 12:20:41 +0100

Douglas Otis wrote:

> Identifiers that are individual, where unless the AUID exactly
> matches a signed header's email-address, is to be considered an
> opaque value.  Being opaque means the AUID sub-structures, and
> particular semantics, are not publicly defined and, therefore,

Note that the text in rfc4871-errata currently says that the
local-part of UAID may or may not be in the same namespace as email
address local-parts.

You seem to assume that they're in the same namespace -- because if
they're not, comparing them does not make sense (exact match
or anything else).

(US passport numbers are 9 digits. US Social Security Numbers are
also 9 digits. But since they're not in the same namespace, an
exact match between passport 123456789 and SSN 123456789 does
not provide useful information -- the numbers could refer to
the same person (in theory, although unlikely) or to different
persons.)

So, even exact match with some email header is useless to the
recipient (unless it somehow knows that the Signer is using same
namespaces for these two fields).

Best regards,
Pasi

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Tue, 10 Feb 2009 17:57:27 +0530

> namespaces for these two fields).

So, entirely opaque to the recipient and solely for the sender's use,
unless decided otherwise (out of band, typically)

This also provides an added layer of security for a reputation model,
I guess - where i= can be a hashed token that is unique + parseable by
a plugin at the recipient ISP and hooks into a reputation system (sort
of what goodmail would do if it plugged into dkim?)

--srs
-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Feb 2009 07:55:27 -0500

> namespaces for these two fields).

Which is why I don't understand why there exist a conflictive MUST 
convey mandate and the receiver "SHOULD take pains" to highlight the 
mismatch.

    Once the signature has been verified, that information MUST be
    conveyed to the Identity Assessor (such as an explicit allow/
    whitelist and reputation system) and/or to the end user.  If the
    SDID is not the same as the address in the From: header field, the
    mail system SHOULD take pains to ensure that the actual SDID is
    clear to the reader.

What value is gain to highlight?

    2822.From != SDID

What sort of pains are we talking about and is there any assurance to 
alleviate the pains? how does the receiver ensure what the actual SDID 
  is?  What if it can't?

Basically what I am saying is that even though the signer is providing 
a opaque value, it is transparent to the verifier (like it was never 
there in the first place).

The only useful concept is to make sure the domain parts are satisfied 
as required by RFC4871.  Beyond that, the verifier really can't do 
anyone more with it. Maybe someone can explain how this helps the user.

I'm proposing the "MUST convey" be changed to "SHOULD|MAY convey"

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Feb 2009 11:49:36 -0800

On Feb 10, 2009, at 3:20 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Note that the text in rfc4871-errata currently says that the local- 
> part of UAID may or may not be in the same namespace as email  
> address local-parts.
>
> they're not, comparing them does not make sense (exact match or  
> anything else).

The i= value is intended to convey the identity on whose behalf the  
signature was applied as indicated in RFC 4871.  When this identity  
exactly matches an email-address found in a signed header field, where  
this email-address IS within a valid email-address namespace, it is  
NOT reasonable to assume the i= value represents a separate namespace  
that collides with the domain's valid email-address namespace!  Only  
when the i= value does NOT match with any signed header field, could  
it be reasonable to consider that the i= value might represent a token  
for on whose behalf the signature had been applied.

> also 9 digits. But since they're not in the same namespace, an exact  
> match between passport 123456789 and SSN 123456789 does not provide  
> useful information -- the numbers could refer to the same person (in  
> theory, although unlikely) or to different persons.)
>

Why require an additional semaphore before a recipient can trust that  
the i= namespace will not collide with the domain's valid email- 
addresses as conveyed within the same message?  DKIM makes it easy for  
collisions to be avoided.  Otherwise, one must assume the i= value  
misrepresents on whose behalf the signature was applied.  The  
misrepresentation issue will have been _created_ by an errata that  
explicitly allows  i= values to represent a namespace that collides  
with valid email-addresses!  It should not.

Allowing the i= value namespace to collide with valid email-addresses  
within the domain gives those implementing DKIM a license to be  
deceptive.  This license to lie undermines DKIM's value and imposes an  
unnecessary change to the protocol that will then require a new  
semaphore to indicate the use of non-colliding i= namespace. :^(

Rather than offering permission to be deceptive, it would be much more  
forthright and reasonable to add a strong admonishment regarding any  
extremely ill considered practice where i= values collide with the  
domain's own valid email namespace!

Is there any domain currently issuing i= values that collide with  
valid email-addresses within the same message?  If so, it seems one  
would be well advised not to trust their DKIM signatures, since not  
being deceptive should not require explicit instruction.

-Doug