At 08:34 AM 10/2/2004 -0700, Dave Crocker wrote:
Ned's note presses us to make sure a number of things are more
clearly stated in the charter. Besides being a contract, I view
a charter as a sales document that explains why this is a good
effort to have underway. So the clarifications would be used to
add.
Here are some of my own suggestions, with some requests for
assistance:
What I don't get - and perhaps it's just me in which case
I would appreciate being educated - is how the problem
stated in the charter of this group (adding signatures to
email) is a different problem than has already been solved
5 times over for email?
Very nicely put. I'm no longer on the IESG, but if I were the
question I would want to see addressed in the chater is why
this effort is expected to succeed in achieving very
widespread deployment when the many previous efforts in this
area have all failed in this regard.
John L. cited long- vs. short-term protection, identity
granularity, and key distribution. Are there other differences
that are (likely to be) significant?
Semantics of the signature. Rather than (or perhaps in addition to) the
question of who sent the mail, we are trying to answer the question of whether
the transmission was authorized by the originating domain. Just like domain
administrators delegate the use of email addresses, they need to be able to
delegate the authority to send messages using a given address in their domain.
Long-term vs. short-term is indeed a difference, although it seems to me that
the primary vulnerabilities here are likely not to be related to key length but
rather the trust root, which for at least some of the proposals is DNS.
- Minimal computational and transactional overhead for
high-volume email servers.
The widespread success of SSL/TLS argues strongly that this
isn't a material issue.
Does anyone have a concrete reason to keep this in the charter?
I think the computational cost issue sounds good to list, but
does not have any real impact on our work, per Ned's example.
A lot of people seem to be concerned about the computational overhead of
signing, but don't have any problem with content filtering. It's hard to make
a comparison since the cost grows differently with message size. There is
definitely more overhead for the signer (since the sender doesn't do anything
right now) but I don't think that putting more of the burden on the
sender/signer is necessarily a bad thing.
- Anonymity when when desired by the sender
This is, at best, a minority taste, and I for one don't think
its presence or absence will materially affect deployability.
I tend to think it is important not to preclude anonymity,
because its role in human communication is rather significant.
However I do not have a sense of how this is likely to have a
real impact on the work of MASS. Can someone clarify?
Again it goes back to the semantics of the signature. If I have to prove who I
am, in addition to showing that I'm authorized to send the message, perhaps by
way of a signed certificate, I think that works against anonymity, and IMO
isn't really necessary for the job we're trying to do.
- Short term protection for purposes of transit
SSL/TLS has this one covered, I think.
Not really. MASS is doing an end-to-end mechanism, whereas
SSL/TLS do a one-hop mechanism.
So the difference is classic object-vs-channel protection.
By "protection" do we mean that we are encrypting the message as well? If so,
I would disagree that it's a requirement. If not, the word seems ambiguous.
- DNS-based key-related queries
This is indeed a distinguishing feature, but there's the
pesky DNSSEC question...
1. Yes, but it is factorable; MASS can note the issue but leave
its solution to others -- this is nice because the others have
been working on the issue for awhile.
2. What is the impact of an authentication failure, when MASS is
used? That is, why threats is it protecting against? If the
impact of a failure small -- e.g., a piece of spam gets delivered
-- then the DNSSec issue is less urgent.
Exactly. Although I'm sometimes concerned that the impact of a failure may not
be small, if it happens to be the message that causes someone to fall victim to
a phishing attack.
-Jim