Subject: [ietf-dkim] Certifying the DKIM public key?

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 19 May 2011 23:32:31 +0200

Hi, all,

recently someone asked me whether it would have any added value if the 
DKIM public key, which is stored in DNS, would be 'certified' in some 
(yet to be determined) way by a 3rd party like VeriSign, Thawte etc.? My 
first reaction was, that it made no sense, but I'm no longer sure 
whether that's the only possible answer. For example: does it have an 
added value if a VeriSign Trust Seal certificate would be used for the 
DKIM public key?

Maybe I should send this question to the domainrep list, as 'certifying' 
a DKIM public key may have more to do with domain reputation and 
accreditation then with DKIM itself.

Anyway, any thoughts on this topic appreciated.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 May 2011 15:17:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Thursday, May 19, 2011 2:33 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Certifying the DKIM public key?
> 
> Hi, all,
> 

The use of plain RSA keys without requiring a third-party certification was a specific design criterion for DKIM.  You could change to using some kind of certificate that is signed by someone else, but you'd need a new key type and corresponding signing algorithm(s) that evaluate the more complex keys and then tie them to whatever your trusted certifiers list is, and would probably pretty much mandate TCP for DNS.

It seems to me this is a bullseye for what VBR is capable of providing.

This is also probably in-scope for "domainrep", I think, but not so much for this WG.  A follow-on DKIMbis WG or individual efforts could add this capability by registering extensions, although you need to accept that the roll-out for that approach once published will be pretty long.

That said, I'd be game to try.  :-)

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 May 2011 16:41:39 -0700

> Anyway, any thoughts on this topic appreciated.
There is value knowing whether labels used to access public keys are valid.

For example, labels should be ensured not to use invalid code points, 
whether or not expressed in punycode form.  DNS is capable of handling 
UTF-8 queries without punycode conversion.  Punycode was to bridge 
applications unable to handle UTF-8.  Now there are two encoding 
standards for punycode, one with string-prep and one without.  
Simplistic prep has been replaced by a sizable list of 3,329 additional 
invalid code-points which now permits use of German essets and the Greek 
final sigmas.

At the system level, a name resolver does not know whether a name space 
must use punycode for non-ASCII or should use UTF-8.  There are two 
popular implementations for the local namespace using UTF-8, which means 
at the system level multiple encoding methods will need to be tried.  
Whether an answer resolved locally would be impossible to determine.  An 
issue ignored by DKIM.

Also see http://tools.ietf.org/html/rfc5201 (HIP) for another approach 
that might make sense when attempting to securely deal with source.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 May 2011 20:53:54 -0400

> Anyway, any thoughts on this topic appreciated.

Off hand,

1 - No Certificate Chaining in DKIM like it is in SSL.

2 - Verifiers need local table for DCA (DKIM Certificate Authority), like
     browser have now.  They are not just going to accept all DCAs and
     the DCA may have give out some payola to get their names
     in the table!

3 - No COMMON NAME (ODID), thus one SIGNER for all messages!

     - Wildcards - Lost of profits for DCA, they will need at least
                   ODID and/or AUID as a "Identity Cookie."

4 - What happens if it fails? Even browsers have learned not to be so
     quick to continue with the SSL cert failures.

VBR can work as the emulation of the "Chain" concept, but #2 is still 
required.  #3 is what we missed out in RFC4671 to prepare this market 
place.  Just like in a SSL certificate the "COMMON-NAME" which would 
be the Author Domain (ODID) will help this DCA market and help them 
prepare the different pricing tiers of non-wildcard vs wildcard.

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

---

From: "John Levine" <[email-masked]>
Date: 20 May 2011 02:22:04 -0000

>(yet to be determined) way by a 3rd party like VeriSign, Thawte etc.?

Sure. See RFC 5518.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 May 2011 08:20:54 -0700

On 05/22/2011 08:02 AM, Dave CROCKER wrote:
>
> 3. As noted, certification was explicitly de-coupled from DKIM.  I'll claim that
> it really is a separate, value-added service and any support of it should be
> through a separate, value-added mechanism.  My own preference would be for using
> a special header-field that contains the cert, with the specification of using
> such certs as saying that they are enabled when included in the set of h=
> covered header fields.
>    

Well, x.509 style certification certainly was. But using DNS is a
form of certification which is arguably not much worse than going
to godaddy and proving that you can receive email from the domain
or whatever weak tests they use to establish that you have control
of the domain. The weak part of DKIM/DNS chain isn't the certification
part (if you believe that godaddy et al aren't problematic), it's the
lack of data integrity in the transport of the dkim rr. Which can
be solved with DNSSEC.

Given how problematic x509 has been for people to get their heads
around, I think that DKIM has done a service in providing an
alternative mechanism/trust root for establishing identity
that is workable and especially with its solution to the revocation
problem.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 May 2011 08:02:55 -0700

On 5/19/2011 3:17 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
...
>> recently someone asked me whether it would have any added value if the DKIM
>> public key, which is stored in DNS, would be 'certified' in some (yet to be
>> determined) way by a 3rd party like VeriSign, Thawte etc.?
...
> The use of plain RSA keys without requiring a third-party certification was a
> specific design criterion for DKIM.  You could change to using some kind of
> certificate that is signed by someone else, but you'd need a new key type and
> corresponding signing algorithm(s) that evaluate the more complex keys and
> then tie them to whatever your trusted certifiers list is, and would probably
> pretty much mandate TCP for DNS.
>

1. There are important differences between 'claims' -- certified or not -- and 
reputation.  Claims are provided by the claimant.  Reputation is provided by 
third-parties.  Certs are specific to the claims.  Reputation can be about 
anything.  And so on.  These really are not equivalent mechanisms, IMO.

2. It might be reasonable to enhance DKIM to support multiple claims.  As of 
now, DKIM has only one:  The signer claims to take /some/ responsibility for the 
message.  (DOSETA now supports multiple claims.)

d/
-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 May 2011 10:33:26 -0700

On 5/22/2011 10:27 AM, John R. Levine wrote:
> I don't see how this is functionally different from VBR. In both cases the
> signer assserts that the message is certified by foo.

Sorry, no.

VBR queries are about an actor, not a message.

Certs can be coupled to a particular message -- this was an interesting semantic 
distinction about Goodmail's certification scheme -- although I believe that 
typically they, too, are only scoped to the actor, not the specific content.

Mechanically, there are useful distinctions between in-band carriage of 
third-party information -- that is, carried with the message -- versus 
independent query, such as to the DNS.  The distinctions variously can entail 
benefits, costs or limitations.

> It occurs to me that since mail certification is likely to make assertions about
> behavior as well as identity, the SSL model in which certs last for a year won't

I believe most certification work is actually about behavior, except when the 
identity-related certification couples one identifier to another (or, my 
familiarly, one identifier to an identity.)

d/

ps.  none of this has anything to do with the current DKIM wg tasks, of course...
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 22 May 2011 13:27:02 -0400

>> such certs as saying that they are enabled when included in the set of h=

I don't see how this is functionally different from VBR.  In both cases 
the signer assserts that the message is certified by foo.  If the 
recipient finds foo to be credible, it checks to see if foo really did 
certify the signer, by a DNS lookup for VBR, or I suppose by checking the 
offered cert to see if the signature is valid, and if the contents include 
the signer's domain and an expiration date in the future.

It occurs to me that since mail certification is likely to make assertions 
about behavior as well as identity, the SSL model in which certs last for 
a year won't work, since behavior can change rapidly.  Either the 
certifier has to issue a stream of short-term certs to everyone it 
certifies, or the verifiers have to check CRLs, which is tedious.  By the 
time you do all that, a DNS check, even one with DNSSEC, looks pretty 
attractive.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 22 May 2011 13:43:38 -0400

> Certs can be coupled to a particular message -- this was an interesting 
> semantic distinction about Goodmail's certification scheme -- although I 
> believe that typically they, too, are only scoped to the actor, not the 
> specific content.

Now I'm really confused.  If the third party knows enough about each 
message to decide whether to provide the cert, why don't they just add 
their own DKIM signature?

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 May 2011 10:49:12 -0700

> time you do all that, a DNS check, even one with DNSSEC, looks pretty

But this is exactly what DKIM is. You prove yourself fsvo "prove"
to the registrar who "certifies" you by virtue of placing your NS
records in the root servers instead of issuing a cert. Nothing
different in *essence* to x.509 certs. The "advantage" that
x.509-style certs have is that you can verify them offline. Except
when you factor in CRL's which in any reasonable scheme you
must do. So yes, DKIM saves quite a bit of overhead by not
caring about the problematic offline verification problem.

There's really not a need of yet another certifier that I can see:
if your DNS is compromised, you have far, far larger problems than
DKIM.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 22 May 2011 14:03:05 -0400

> records in the root servers instead of issuing a cert.

Registrars, as we all know, rarely check any credential beyond the 
confirmation code from the credit card charge.  The thought here is to 
provide assertions more relevant to managing e-mail.

I'm still not seeing what a cert provides that couldn't be handled by VBR 
or another DKIM signature by the certifier.

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Sun, 22 May 2011 16:26:31 -0500

> time you do all that, a DNS check, even one with DNSSEC, looks pretty 

That's how it works at the IP level today.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 May 2011 23:26:27 -0400

John R. Levine wrote:
> confirmation code from the credit card charge.  

hmmmm,  doesn't that depend on the cert being purchased?  There is a 
higher due diligence done for the more expensive "seal" which comes 
with a higher indemnity.  AFAIK, depending on your PCI level, you 
can't get the "el cheapo" cert like the Turbo SSL offered by GoDaddy 
because auditors will fail you.

> or another DKIM signature by the certifier.

+1, I think VBR can address the "wildcard" signer which may not be 
desirable (by the receiver and by an 3rd party authority).   But I 
think you answered this in your RFC security session:

    The receiver of a message with a VBR-Info header field MUST ignore
    certifiers that it does not trust; otherwise, a bad actor could just
    add an authority that it has set up so that it can vouch for itself.

No matter what, like everything else, there needs to be a "White List" 
of VBRs that is either defined locally or via a centralized source.

The problem, unlike the browser market, is that SMTP vendors do not 
have a common source to do this and even then, they may only want to 
do this for selected VBR records, Author Domains and signers.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 May 2011 11:17:51 -0700

> their own DKIM signature?

(Note that you are the one who introduced the construct of certifying a message.)

In any event, there always needs to have an independent means of authenticating 
that a statement by a third party really is by them, whether it is through 
querying a portion of the DNS they own or by using their domain name to verify 
something in a message.  So they probably /will/ add their own DKIM signature.

But that's quite different from adding a signature with the domain of the 
organization producing the message, since this latter is the subject of the 
reputation/certification.  (One could design this to remove the need for the 
latter signature, even while still including their domain name, I suppose.)

The bottom line to this sort of exchange is that it seems pretty clear that as a 
community we are not clear about concepts or details for this topic.  That one 
or another person thinks one or another issue has an obvious answer is turning 
out to be a poor indicator of actual community understanding or agreement.

As an impressive example of even deeper misunderstanding:

> On 5/22/2011 10:49 AM, Michael Thomas wrote:
>> different in *essence* to x.509 certs.

DKIM has almost literally nothing to do with proofs made to a DNS registrar. 
For example, it says nothing about the relationship between a domain name and a 
brand or company name.

DKIM merely says that who ever owns use of a domain name is asserting "some" 
responsibility for the signed message.

In extremely abstract terms, a DKIM signature relates to a reasonably constant 
construct that one might call an "identity" but it does not label the identity, 
except with the domain name.

More importantly, there are none of the claims, assertions or endorsements that 
go along with Certs, except for the mild one noted above.

One would have expected a former author of the spec who so-often proclaims their 
expertise to understand the semantics of DKIM better.  On the other hand, it 
does nicely show that implementing code doesn't mean understanding what it is for...

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 May 2011 11:43:12 -0700

> As an impressive example of even deeper misunderstanding:

More of CROCKER's famed civility.

> For example, it says nothing about the relationship between a domain name and a

Where exactly did I say anything about a "brand" or a "company"?
Oh, I didn't.

> responsibility for the signed message.

Yes, and the way that they got to "assert" that was by convincing
a registrar to allow them to create and maintain NS records in the
root servers.

> except with the domain name.

A domain name is an identity. RFC4871 calls it the signing identity.

> go along with Certs, except for the mild one noted above.

Assertion of identity is "mild"? It's the *key* assertion.

> does nicely show that implementing code doesn't mean understanding what it is for...

I'm not a "former" author.  But thanks for the smear anyway.

Mike