At 10:32 PM 3/3/2004, Mark Baugher wrote:
At 08:49 PM 3/3/2004, Hallam-Baker, Phillip wrote:
> >Sure it looks great in theory, but the cost of deploying all
> >those end user certificates is simply beyond most enterprises.
>
> It seems to me that your pinning the apparent failure of X.509
> PKI on the end-to-end security concept.
No, SSL and Authenticode are tremendously successful, the best
security we have on the Internet in fact.
You shifted the argument. I said "PKI" and you said "SSL" and
they are not the same thing, are they?
It is the email area
where we have failed - until we started to use STARTTLS.
> I use PGP Mail whenever I need authentication and encryption.
> I consider it to be successful for my personal use.
I don't consider PGP to be any more successfull, i get far more
S/MIME signed messages than PGP and that is ignoring the S/MIME
bias from PKIX and S/MIMe list membership. The vast majority
of MUAs support S/MIME and have done for years.
So what? The vast majority of MUAs support PGP as well. And I don't
think you get far more S/MIME signed messages than PGP signed messages
from the ASRG lists.
The failure has been getting the end users to participate.
it was just too hard.
> >If you look at the problem from a risk assement point of view
> >it is entirely reasonable to secure email internaly by using
> >SSL to secure communication with the email server and then to use
> >SSL to secure the hop over the Internet where the email is
> >most likely to be intercepted.
>
> There are two problems with this notion. The first is that
> various intermediate systems have access to the communication
> to read and alter.
Sure, but that is irrelevant. Almost none of the email on the
internet is encrypted in any form. The vast majority of messages
that are encrypted use STARTTLS.
RFC 3207 did not intend STARTLS to serve to protect user's email.
That's not what it's for. Users who need email confidentiality
need confidentiality from interlopers who are most likely to have access
to their messages such as the mail operator.
> The second is that there is no guarantee
> that any pair of intermediate systems actually secure the
> hop between them. The secure connection established by the
> two systems is appropriate for their own security needs rather
> than for the end-to-end traffic they convey over that connection.
Again, wrong comparison. STARTTLS is a bicycle. It has nowhere
near the power and capabilities that a tank offers. But it will
get you to your destination far faster than walking.
> >Sure they might be apples and oranges. But if you put apples
> >and oranges together you have a fruit salad.
>
> I do think STARTLS might have a role to play in antispam if
> there were some scalable way to do the authorization.
The problem is advertising the fact you support STARTTLS in
the DNS.
See section 3 of RFC 3207.
it is not an authorization problem.
There is always an authorization problem.
Mark
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg