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

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Feb 2009 07:52:51 +0100

Dave,

On 1/27/09 8:23 PM, Dave CROCKER wrote:
> Jim,
>
>
> Jim Fenton wrote:
>    
>>>     1. 1399 received no substantive discussion and was then declared
>>> redundant with 1519.  So citing it winds up confusing the current
>>> discussion.
>>>        
>> Issue 1399 was open for over 4 months, surely enough time for anyone who
>> wished to comment to do so.  If there is a requirement for a specific
>> amount of substantive discussion on an issue, please cite it.
>>      
>
> Since 1399 has no discussion of i= vs. d=, and since it was declared redundant
> with 1519, the issue is moot.  It's irrelevant to the current discussion.
>
>
>    
>>>     2. 1519 had nothing to do with the choice between d= vs. i=.  It
>>> asked a very different question about i=.
>>>
>>>     3. One could argue that all discussion "assumed" i=, but that's a
>>> very different claim that one that says we considered d= vs. i= and
>>> chose i=.
>>>        
>> In message http://mipassoc.org/pipermail/ietf-dkim/2008q3/010582.html ,
>> Stephen summarizes the issues around issue 1519 well, notes that the
>> draft includes matching the local-part of i=, and invites further
>> discussion.  There was none, so the issue was closed about 10 days
>> later.  Since d= does not have a local-part, it would not seem that it
>> qualifies.
>>      
>
> You think that failing to discuss an topic that was outside the scope of the
> cited issue and, in fact, was not raised then, is somehow relevant to the
> current discussion?  I don't understand that logic.
>
> More importantly, it seems a distraction from the current discussion:  There is
> a real problem and it needs real resolution that the current specification does
> not provide.
>
> d/
>    

I think Jim's point was that if the criteria for this errata to be 
accepted is that it would have received consensus, there is evidence to 
suggest that not only would it not have done so, but at the time the 
consensus would have gone, and in fact did go, the other way.  The 
evidence is that the issue was raised, nobody commented on it, and the 
matter was closed.  Of course operational experience can provide us with 
reasons to change our views, but those were the views at the time, as 
recorded by the tracker.

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 Feb 2009 23:26:48 -0800

Eliot Lear wrote:
>   The 

Eliot,

You are seriously trying to pursue this?

1.  The issue was not raised.

     Since you and Jim feel otherwise, you should provide the exact text of 
messages to the contrary that show the specific problem and the clear wg 
consensus about it.  What you should not do is try to cite Issue numbers that 
contain text that has nothing to do with this specific topic, as well as not 
showing much consensus.

2.  But, really, all of this misses the point that we have a problem now.

     The problem is now, it is real and it is substantial.

3.  Attempting to invoke a hypothetical about what might have been decided about 
it in the past -- or, rather, what you wish would have been decided about it -- 
is pretty astonishing.

What matters is consensus about fixing the problem... now.

d/

-- 

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Feb 2009 13:31:30 +0100

As I wrote, I'm neutral to positive on MOST of the errata, but my memory 
and Dave's differ.

> 1.  The issue was not raised.

To be fair, the issue was raised after last call, and it was vague.

> This guidance is not in dkim-base (purposefully),
> but I believe that we had intended i= to provide that clarity.

On the other hand, Doug Otis discussed the use of i= as early as 8/30/05 
in his email to you of that date.  You could have picked it up and run 
with it but you demurred.  Ok.  Who knew?  As you wrote, it doesn't 
really matter if the issue is so important that it requires a fix now.

I think perhaps it would help, Dave, if you could step through the 
ramifications of your concerns.  Also, I have the following additional 
questions:

>    However the specification defines two, potentially different
>    identifiers that are carried in the DKIM-Signature: header field and
>    might be delivered to a receiving processing module that consumes
>    validated payload.  The DKIM specification fails to clearly define
>    what is "payload" to be delivered to a consuming module, versus what
>    is internal and merely in support of achieving payload delivery.

This statement to me argues that the matter is substantial and clearly 
requires WG participation.  What it doesn't say is how the confusion 
manifests itself.  Can you please clearly do so with examples?  The 
reason I ask is that I would like to more clearly separate the problem 
from the solution.

Also:

> If the UAID is not the same as the address in the From:
>       header field, the mail system SHOULD take pains to ensure that the
>       actual UAID is clear to the reader.

If you are going to go to lengths to separate the Identity Assessor from 
other parts of the system, it makes it more confusing when you continue 
the old phrasing of "mail system" above.  Which mail system?  Who is 
responsible for that?  I presume you mean the signer, since the signer 
is the one who inserts the UAID.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 Feb 2009 11:48:43 -0800

Eliot Lear wrote:
> ramifications of your concerns. 

I don't understand your question.  What is it about the Introduction to the 
Errata that is not sufficiently clear or complete?

You appear to be asking about the ramifications of being non-interoperable, and 
I know you don't really mean that.

>    What it doesn't say is how the confusion 
> manifests itself.  Can you please clearly do so with examples?  

You need an example of the problems that can ensue from having one side of a 
protocol exchange consider one attribute to be the sole output and another side 
consider two attributes or a different one attribute to be the output?

Really?

> is the one who inserts the UAID.

damn. damn. damn.  yes it does make it more confusing.  yes I meant to change 
it.  grrrr.  sorry.

I believe the intent of that sentence is something like "receiving MUA", but on 
reflection, I'm not sure I fully understand what this requirement really is or 
what is considered reasonable for satisfying it.  And I mean that as a 
specification-clarity issue, not an user interface philosophy issue.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 2 Feb 2009 13:56:02 -0800

,---

3.  Section 2.8 Signing Domain Identifier (SDID)

   Original Text:   (None.  Additional text.)

   Corrected Text:   A single, opaque value that is the mandatory   
payload output of DKIM and which refers to the identity claiming   
responsibility for the introduction of a message into the mail stream.

'---

Although the i= (UAID) value can be opaque in respect to the actual  
identity being referenced,  the signing domain d= (SDID) is not  
opaque.  A domain that returns valid keys should not be considered  
opaque.

The corrected text could be:

The d= value (SDID) contains the domain that locates a public key per  
RFC 4971.  A signature confirmed with this key verifies the domain  
applied the signature to claim responsibility for the introduction of  
the message into the mail stream.

-Doug

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 2 Feb 2009 19:01:57 -0500

> opaque.  A domain that returns valid keys should not be considered
[> ]

I think what is intended by "opaque" in this context is that it should be opaque to the Identity Assessor, i.e. it should be treated as an opaque identifier and no knowledge about DNS domain structure should be applied.  For example, if the SDID was subdomain.example.com, the Identity Assessor should not make any use of the fact that example.com is the parent domain of the SDID, it should just treat the whole domain name as an (opaque) identifier string.

Obviously it's not opaque to the verifier in that it's necessary to look up the keys... but the opaque label is attached to the output of the verifier, not its input.

Ellen

---

From: Douglas Otis <[email-masked]>
Date: Mon, 2 Feb 2009 17:38:08 -0800

On Feb 2, 2009, at 4:01 PM, Siegel, Ellen wrote:

> I think what is intended by "opaque" in this context is that it  
> should be opaque to the Identity Assessor, i.e. it should be treated  
> as an opaque identifier and no knowledge about DNS domain structure  
> should be applied.

Ellen,

An identity need not be in the form of an email-address.  When  i= [email-masked] 
  and d=ietf.org, there is a stark difference between the opacity of  
i= and d= values.

A domain within the d= parameter is always transparent.  It tells a  
great deal about who owns it, even for domains without whois  
information.

For example, when one does a whois on ietf.org you'll get:

Domain ID:D36473-LROR
Domain Name:IETF.ORG
Created On:11-Mar-1995 05:00:00 UTC
Last Updated On:14-May-2008 22:29:36 UTC
Expiration Date:12-Mar-2011 05:00:00 UTC
Sponsoring Registrar:Network Solutions LLC (R63-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:40362704-NSI
Registrant Name:IETF Trust
Registrant Organization:IETF Trust
Registrant Street1:1775 Wiehle Ave
Registrant City:Reston
Registrant State/Province:VA
Registrant Postal Code:20190
Registrant Country:US
Registrant Phone:+1.7037289264
Registrant Email:[email-masked]
Admin ID:40362705-NSI
Admin Name:Ray Pelletier
Admin Organization:IETF Trust
Admin Street1:1775 Wiehle Ave
Admin Street2:
Admin Street3:
Admin City:Reston
Admin State/Province:VA
Admin Postal Code:20190
Admin Country:US
Admin Phone:+1.7037289264
Admin FAX:+1.7037797463
Admin Email:[email-masked]
Tech ID:40362705-NSI
Tech Name:Ray Pelletier
Tech Organization:IETF Trust
Tech Street1:1775 Wiehle Ave
Tech City:Reston
Tech State/Province:VA
Tech Postal Code:20190
Tech Country:US
Tech Phone:+1.7037289264
Tech FAX:+1.7037797463
Tech Email:[email-masked]
Name Server:NS1.AMS1.AFILIAS-NST.INFO
Name Server:NS1.MIA1.AFILIAS-NST.INFO
Name Server:NS1.SEA1.AFILIAS-NST.INFO
Name Server:NS1.YYZ1.AFILIAS-NST.INFO
Name Server:NS1.HKG1.AFILIAS-NST.INFO
Name Server:NS0.IETF.ORG

One might inquire about this domain's name servers, and the IP  
addresses used by the name servers to further determine more about  
this fairly transparent identity that indicates who provides name and  
routing services.

However, whois for random.ietf.org returns NOT FOUND, returns no name  
server, and provides no associated IP addresses, although [email-masked] 
  represents a legal value for the i= parameter.  NOT FOUND, no name  
server, and no associated IP addresses is not be a valid result for  
the d= value.

> For example, if the SDID was subdomain.example.com, the Identity  
> Assessor should not make any use of the fact that example.com is the  
> parent domain of the SDID, it should just treat the whole domain  
> name as an (opaque) identifier string.

Being able to access public keys based upon a domain confirms  
ownership hierarchy and indicates both the existence and the  
involvement of a supporting name server.  A name server for a domain  
transparently indicates ownership hierarchy.   On the other hand, [email-masked] 
  may not relate to any specific identity or name server whatsoever,  
and yet this is completely valid for RFC 4871.  As such, the i= value  
might be considered opaque,  but the d= value should not.

> Obviously it's not opaque to the verifier in that it's necessary to  
> look up the keys... but the opaque label is attached to the output  
> of the verifier, not its input.

Why would one wish to attach a label of opaque to ietf.org in the  
example given?   How does the use of opaque in the case of the d=  
value add clarity to RFC 4871?  For an identity to be transparent, it  
does not need to be in the form of an email-address.  An identify is  
made transparent when supported by a name server verified as being  
associated with the message.   How could the identity be any more  
transparent?

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Tue, 03 Feb 2009 07:20:54 +0100

On 2/2/09 8:48 PM, Dave CROCKER wrote:
> I don't understand your question.  What is it about the Introduction 
> to the Errata that is not sufficiently clear or complete?
>
> You appear to be asking about the ramifications of being 
> non-interoperable, and I know you don't really mean that.

That's right.  What I mean is this: what is the case that gets you to 
non-interoperability?  How is i= used such that it breaks things?  You 
write in your introduction:
> For DKIM to be interoperable and useful, signer and consumer must 
> share the same understanding of the details about the name.
and:

> The DKIM specification fails to clearly define what is "payload" to be 
> delivered to a consuming module, versus what is internal and merely in 
> support of achieving payload delivery.
I know what you're referring to, but I don't see the interoperability 
failure.  Where does interpretation of i= lead to something bad 
happening/  Clearly you've been working into problems, so please explain 
in some additional detail.

Eliot