Subject: [ietf-dkim] Please post issues with draft-dkim-rfc4871-errata-03

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Feb 2009 08:13:55 -0800

FOlks,

In anticipation of a working group Last Call for the Errata, would anyone else 
with concerns about the draft please post them so we can discuss and resolve them?

   <http://dkim.org/ietf-dkim.htm#errata>

As already noted, posting suggestions for specific changes greatly aids in 
understanding the impact of the requested change.

Thanks.

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Feb 2009 11:56:30 -0800

On Feb 9, 2009, at 8:13 AM, Dave CROCKER wrote:

> Folks,
>
> In anticipation of a working group Last Call for the Errata, would  
> anyone else with concerns about the draft please post them so we can  
> discuss and resolve them?
>

Dave,

The issue appears to be an over zealous use of the word opaque in an  
attempt to reiterate that there is an uncertain mapping of entities to  
email-addresses.  Such as, perhaps multiple entities might be able to  
use "[email-masked]".   Of course, the issue of entity mapping is  
always an internal matter for the domain.   Combining this concept  
with DKIM definitions is fairly confusing.

Useful errata information might mention:

a) The display name, in conjunction with an email-address, is not  
directly validated by the DKIM verification process.

b) Only when the header containing the email-address is signed, can it  
be presumed that the display name is in compliance with the domain's  
practices.

c) Use of subdomains below the d= value domain requires an unverified  
assumption that the d= value domain is authoritative for the subdomain  
namespace.

d) When the i= identity is not found within the signed header fields,  
although it is in the form of a email-address, it should not be  
assumed to represent a valid email-address.

The proposed errata use of the word opaque to describe the d= value,  
in addition to the i= value offers _no_ additional clarity.  The DKIM  
signature validates a domain indicated by the d= value as possessing  
the private key used to sign the message.   There is little benefit  
calling this validated domain "opaque".

After all, authorization to include a Mail From domain for an SMTP  
client might be called "domain authentication" with respect to any  
purported responsible address. :^(

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Feb 2009 22:56:29 +0100

Just to be clear, it is my intent to post an alternative tomorrow, which 
I believe should be considered as such.  The amount of verbiage being 
proposed is excessive, given the stated problem.  As such, I'd ask that 
prior to a WGLC we gauge consensus on approach.

Thanks,

Eliot

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Feb 2009 10:22:14 -0500

On Mon, Feb 09, 2009 at 11:56:30AM -0800, Douglas Otis wrote:

>in addition to the i= value offers _no_ additional clarity.

Given something like this:

d=good.rep.example.net or
d=bad.rep.example.net

do not assume that those identifiers mean "good" and "bad". Good and
bad could be the names of two different companies. A signer could sign
like this instead:

d=53302.rep.example.net or
d=9999.rep.example.net

and this would enforce to the verifier that no meaning should be placed
on what d= contains.

d= is just an identfier that is used to look up the public key and
could further be used as a key into a reputation system.

-- 
Jeff Macdonald
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Feb 2009 12:23:02 -0500

Jeff Macdonald wrote:
> d= is just an identfier that is used to look up the public key 

Jeff,

It a DNS DOMAIN and a DNS DOMAIN is a well defined entity. And this d= 
DNS DOMAIN must match the 2822 (DNS) Domain.  It is well forth, 
bloody, scared specific 1st PARTY only signing requirement. It does 
not lack clarity. It is not obtuse, it is not "hard to understand or 
explain," nor is it unintelligible, and it is certainly not opaque.

-- 
Sincerely

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

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Feb 2009 12:41:28 -0500

On Tue, Feb 10, 2009 at 12:23:02PM -0500, Hector Santos wrote:
> DNS DOMAIN must match the 2822 (DNS) Domain.

yes, in my examples, {good,bad}.rep.example.net are valid DNS domains.

> It is well forth, bloody, scared specific 1st PARTY only signing
> requirement.

I don't understand what you are saying here. d= can have domains that
are considered by some to be 3rd party too.

> It does not lack clarity. It is not obtuse, it is not "hard to
> understand or explain," nor is it unintelligible, and it is certainly
> not opaque.

I think we all agree that d= is a domain. The spirit of using the word
opaque was to mean "don't read into what that domain may represent".

-- 
Jeff Macdonald
[email-masked]

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 10 Feb 2009 12:47:14 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, February 10, 2009 12:23 PM
> To: Jeff Macdonald
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ietf-dkim] Please post issues with draft-dkim-rfc4871-
> errata-03
> 
> Jeff Macdonald wrote:

Hector,

There is no requirement in RFC4871 (DKIM Base) that the d=domain must
match the 2822 (DNS) domain. There is no requirement that it be 1st
PARTY only signing as you put it. The relevant section of 4871 is as
follows:

d=  The domain of the signing entity (plain-text; REQUIRED).  This is
       the domain that will be queried for the public key.  This domain
       MUST be the same as or a parent domain of the "i=" tag (the
       signing identity, as described below), or it MUST meet the
       requirements for parent domain signing described in Section 3.8.
       When presented with a signature that does not meet these
       requirement, verifiers MUST consider the signature invalid.

I believe you are thinking of the ADSP draft, which is not what the
errata or bis (whichever path is taken) discussion is about.

Mike

Michael Hammer - [email-masked]
Web Operations Security
AG Interactive/americangreetings.com
Tel: 216-889-5304
Cell: 216-849-8397

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Feb 2009 06:18:04 -0500

MH Michael Hammer (5304) wrote:
>> DNS DOMAIN must match the 2822 (DNS) [From] Domain.  It is well forth,
> match the 2822 (DNS) [From] domain. There is no requirement that it 
 > be 1st PARTY only signing as you put it. The relevant section of
 > 4871 is as follows:
> 

Yes and no.

Its all inter-related.

Consider:

1) From: [email-masked]
    DKIM-Signature: d=domain1.com
                    i=[email-masked]

2) From: [email-masked]
    DKIM-Signature: d=domain1.com
                    i=[email-masked]

3) From: [email-masked]
    DKIM-Signature: d=otherdomain.com
                    i=[email-masked]

In 1, everything is kolser, d=/i= matches, in fact, redundant (i= is 
not necessary.  It's a clear example of a 1st party signature.

In 2, everything is kolser, d=/i= still satisfies the requirements, 
but you begin to touch base with '3rd party' signing.

In 3, everything is kolser, but you have a clear 3rd party situation.

According to the errata, for 2 and 3 (less so 2) there is a mismatch 
and the receiver SHOULD take pain to point this out to the user.

In other words, the confusion with the equality or inequality with the 
2822.From address with that of i= is indirectly related to d= because 
d=/i= domain must be correct according to RFC 4871.

The only time there is "question" about a valid signature is when in 
fact, there is a 3rd party signing involved and the authorization of 
the author domain allowing it.

For 1st party signatures, it is less of an issue, 2822.From must 
conform to d= domain, or vice versa and therefore by virtue of the 
specification, so those i= must conform to the same domain name space.

-- 
Sincerely

Hector Santos, CTO

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Feb 2009 12:53:33 -0800

FYI, apologies, folks.

The latest version of the draft is errata-02, not errata-03.

d/

-- 

   Dave Crocker