ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
> Fine, so let's run with these. The first of these canont be achieved with
the
> present infrastructure unless protection is restricted to long hop
situations,
> doesn't protect the entire message, or both. This then exludes the ideal of
> protecting the entire message end to end, which is exactly the goal some
people
> seem to be striving for, and in so doing letting the best be the enemy of
what
> you yourself are now saying is good enough.
I view your "ideal" as being just that: something that's
nice and that should be mandatory to support,
There you go again, letting the best be the enemy of the good. End to end
signatures across entire messages are incompatible with current email
infrastructure. Making this a mandatory part of this service will kill it dead
as people try to use it and have it fail on them.
but my "good
enough" is that I'd like senders to be able to make a
risk/reward decision on the security/robustness tradeoff.
Here, the (security) best/ideal is, IMO, the enemy of the
(robustness) good.
Quite true.
A MASS protocol which fails verification
some large percentage of the time, IMO, is a failed
protocol.
That's exactly the point, and that's why mandating suport of end to
end operation is a mistake.
> The second of these argues stringly that accreditation has to be part of
the
> work we do, because without it I see no way to perform the correlation
you're
> after.
The home domain is one source of "accreditation", albeit
self-referential. More (and independent) sources of
accreditation are obviously better.
Indeed.
> > If you have a different set of metrics, please state them.
>
> I have stated my metrics. I see nothing about them that's in any way
circular,
> so I guess this conversation is over.
Ok, let's try this again: you said:
I have stated what I regard "good enough" to be so many times it isn't
funny. For me "good enough" is something that:
(1) Can be widely deployed.
(2) Offers significant assistance in the fight against spam.
Let's, um, run with these. (1) I guess we agree on, though I
view it as just a protocol requirement.
It is much more than that. We're defining a service, one which will probably
include at least three protocols (signature, obtaining keys, accreditation). We
need those plus a clear and concise description of how they are to be employed.
The second... you've
lost me. I don't know how to evaluate what is "good enough"
with such a vague goal.
It sure doesn't seem vague to me, but this is really only relevant to the
acceditation issue, it probably isn't worth discussing further.
Ned