Subject: RE: [dix] Email Verification with Dix - a Possible Method?

From: "David Fuelling" <[email-masked]>
Date: Thu, 8 Jun 2006 12:40:19 -0400

Hi Dick,

Great points, especially wrt to secure DNS.  

DH> Interesting concept to distribute email verification. A modification 

DH> on it would be *if* we get secure DNS, that the domain would be able 

DH> to have a public key available and it could digitally sign the email 

DH> to the persona URL. This lets the world not have to *trust* a 

DH> centralized email verification service.

Just to clarify (not sure if you actually meant this or not) that the scheme
I had in mind would allow an email_verification_service at every domain
(potentially).  If a given domain didn't want to actually run the
verification service, they could delegate the responsibility to whomever,
via dix discovery.  There wouldn't be a centralized verification service
(unless everybody delegated to the same service).  

You're right, though...secure DNS could make the whole thing much more
secure (although, in the current DNS system, it seems like it would be
pretty difficult for a random attacker somewhere on the net to spoof a
conversation between a random email address domain and a random SP.  It
seems to me that the attacker would probably need to have compromised the SP
or the email_verification_service, or an ISP thereof to perform a DNS
spoofing attack)....though I'm not an expert in that realm.

David

[email-masked]

> -----Original Message-----

> From: Dick Hardt [mailto:[email-masked]]

> Sent: Thursday, June 08, 2006 2:19 AM

> To: [email-masked]; Digital Identity Exchange

> Subject: Re: [dix] Email Verification with Dix - a Possible Method?

> Hi David

> Interesting concept to distribute email verification. A modification

> on it would be *if* we get secure DNS, that the domain would be able

> to have a public key available and it could digitally sign the email

> to the persona URL. This lets the world not have to *trust* a

> centralized email verification service.

> Having said that, I think there is a good likelyhood that trusted

> email verification services will be offered for free, which means

> that A1 may become widely adopted if it is as simple as todays email

> process, but that the user only has to do it once. Since only one (or

> maybe a few) sites do the verification, each domain does not need to

> do any config and the user can have any email address.

> To pick up on the value of verified email, there is another use of an

> verified email address (or for the privacy conscience, a verified

> hash of an email address). ACLs. It is a total pain to give certain

> people access to a resource. Many of the private space wikis use

> email invites. Taking that a step further, you enter in the email

> addresses of who you would like to have access (email is an easy ID

> for people), and your invitees prove they own that email address --

> essentially it is the attribute that grants them access.

> -- Dick

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 13 Jun 2006 13:54:52 -0700

> From: Chris Drake [mailto:[email-masked]] 
> Hi David,
> 
> DKIM is one of at least 3 different serverside email 
> verification protocols - the other lesser one is SenderID aka 
> CallerID from Microsoft, and the really big one is SPF.  
> Yahoo and gmail are the only people doing DKIM that I know of 
> (check your own gmail headers - you can see it in there:
>   DomainKey-Signature: a=rsa-sha1; q=dns; ...

Actually SenderID and SPF are the same as far as the sender is concerned. There are people who have the peculiar notion that the SENDER of an email should be able to prevent the RECIPIENT from using evil proprietary software to scan their email.

Tough.

I make it a point to scan each and every email received from open source types using the PRA.

As you might guess I have very little time for the specific doctrine of open source theology that caused the split. The Microsoft license was fully compliant with the traditional IETF terms.

> S/MIME is better than all the above, since it's client-side 
> instead of serverside (cannot be spoofed by other users of 
> the same ISP or webmail provider) - but S/MIME itself relies 
> on some earlier "click here to confirm you own this email 
> address" check, none of which probably use SPF/DKIM/SenderID

Actually S/MIME and OpenPGP both have issues which is why Jon Callas and myself were invovled.

They are both very good for a certain application, they are not very well suited for the specific application addressed by DKIM.

I have proposed a scheme which is a synthesis of an extended DKIM and SMIME/PGP. The basic idea is to use DKIM for authentication, augmenting it with a means of accessing a certificate for the key discovered in the DNS so that a receiver can obtain information about the sender.

S/MIME and PGP are used to protect the confidentiality of outbound email. There is a small amount of glue. In point of fact either message format is just as good as the other or as near so as makes little odds. The reason for insisting on support for both is that I am completely sick of people thinking that there is still a standards war going on. And so for that matter is PGP Inc which has been selling a pretty nice SMIME implementation for years. 

Support for end user keying is layered in using XKMS 2.0 which is a W3C standard that supports key discovery, trusted key discovery and provisioning.

I presented a paper on this scheme to the 2006 NIST PKI conference.