ietf-mailsig
[Top] [All Lists]

Re: Good as the enemy of OK

2005-01-14 10:16:20

On Fri, 2005-01-14 at 07:12 -0800, Michael Thomas wrote:
 > So, I ask, why are we trying to do more than find the immediately 
 > preceding responsible party?

To which I'd say that surely evangelizing TLS for the last
hop out of and into your domain is an easier job than a
completely new protocol? 

There is a difference between the two. There's three levels at which we
can attempt to evaluate trust:

First, we could attempt to authorise a given email for its entire
lifetime, through multiple transitions through the mail system and
mailing lists. For this we would use a signature, and hence a
reputation, tied to the address in the From: header. I think this has
been deemed to be too hard for MASS, but GPG and S/MIME attempt it. 

Second, we could attempt to authorise a single transition through the
mail system. We'd use either the RFC2821 MAIL FROM address, or the most
recent RFC2822 sender (From:, Resent-From:, Sender: or Resent-Sender:).
The latter of these is what MASS seems to have settled upon.

Third, we could do only a single hop from one system to another. That's
what IP-based blacklists do, that's what SPF actually achieves, and
that's what CSV does. And that's what the proposed TLS-based system
would do, too.

I quite like the idea of using TLS certificates for authorisation
instead of IP addresses. It may make a useful addition to the CSV-CSA
proposal. Rather than just specifying acceptable IP addresses, we could
also keep the fingerprint of the TLS certificate in DNS too. Does the
KEY RR allow that?

It would solve the problem of senders with dynamic IP addresses quite
effectively. 

-- 
dwmw2


<Prev in Thread] Current Thread [Next in Thread>