Subject: 3c. message verification (Was Re: [Asrg] Re: 2. Uselessness of C/R)

From: Bruce Lilly <[email-masked]>
Date: Fri, 30 Jan 2004 11:56:23 -0500

> Date: Wed, 28 Jan 2004 21:55:58 -0500
> From: Yakov Shafranovich <[email-masked]>

> Hallam-Baker, Phillip wrote:
> 
>>>Wouldn't a profile of S/MIME that stores keys in DNS achieve 
>>>essentially 
>>>the same thing?
>>
>>Not quite, there is a major semantic shift taking place here,
>>it is the domain owner rather than the email sender being 
>>authenticated. and actually the authentication may be for the
>>sole purpose of getting an accreditation.
>>
> 
> 
> What I meant is: isn't S/MIME with keys in DNS be the same thing as 
> DomainKeys?
> 
> 
>>I might send you a mail from turtlerecall.com through comcast.net
>>and comcast.net sees it comes from a legit user who is not sending
>>excessive quantities of email and sign it under their domain and
>>policy and get the benefit of an accreditation that VeriSign 
>>provides.

Hmmm, that would be the same Verisgn that engaged in the moral equivalent
of spamming (wildcard DNS entries leading to unsolicited marketing) last
year?  I suppose that could be called a benefit to the extent that it
could be used for filtering -- but there may be some disagreement as to
whether the involvement of Verisgn indicates the presence or absence of
spam.  In any event, this isn't a filtering discussion...

Nor, for that matter, is this a C/R discussion, hence the change in
Subject.

>>Otherwise you need an accreditation for every single domain, not 
>>a cheap solution.

If DNS is to be used, and signing is to be used to validate the source
of a message as being that domain, then third party accreditation is
not necessary.  One could simply use a public key cryptography scheme
such as DNSSEC KEY RRs.

> Why do we need accreditation? The whole point of Domain Keys and similar 
> solutions, is to tie the email to the original domain, not a specific 
> accreditation authority. The DNS packet size restricts large 
> certificates from being used with any DNS/PKI approach, and would 
> require external reputation and accredition systems anyway.

There are other issues. I believe DNSSEC mentions some issues involving
sharing a private key for use over a domain.

If validation is to be used for individual senders, identified by email
address, DNS probably isn't the right place for the keys for other
reasons.  There has been some limited discussion about this on the
ietf-822 mailing list; some issues are mentioned in the message archived
at http://www.imc.org/ietf-822/mail-archive/msg03987.html
and a brief outline of how keys might be handled via an SMTP extension is
in http://www.imc.org/ietf-822/mail-archive/msg03941.html

> With S/MIME we can have the outgoing MTA or MUA sign the message, or 
> even both: MUA signs with sender key, and MTA resigns the signed message 
> body with the domain key. This way you can have the same effect as 
> Domain Keys seems to provide, plus a possibility for sender 
> authetication as well.

And the possibility of encryption.  There is even the possibility of
step-by-step verification (each successive MTA handling a message
signs what it receives using S/MIME), though an end-to-end verification
is likely to be more practical.  And if MTAs handle the keys associated
with a sender's email address, the signing and verification can be
performed at the MTA level, transparent to the MUA and user.

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