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?
Intertwined with the short-vs-long is the option of having less-than-perfect
protection. If the resulting scheme is deployable but is unsuitable for signing
million dollar contracts, so be it. Similarly, if the scheme cannot provide end
to end protection but is effective in making transfers between parties that
don't know each other work better, so be it.
- Automated signing of outgoing messages by any SMTP-
initiating entity.
Not only is this doable with off the shelf stuff already, I
believe there are always specifications in the S/MIME space
describing exactly how to do it.
If a protocol is really user-to-user, a user's role can often be
performed by an agent. Hence an MUA-to-MUA protocol, like we are
discussing here, can typically be done by an outbound or inbound
MTA. As Ned notes, the PEM work had mplementations that did
MTA-MTA signing.
While I think we need something that can be done MUA-to-MUA, it isn't
at all clear to me that this should be our primary focus.
- 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.
I think getting rid of it would be a really good idea.
- 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?
That's exactly my point - I think it is mostly irrelevant, and we cannot afford
irrelevancies. I cannot imagine how a scheme that fits within the realities of
present-day email could end up preventing anonymous communications, so why
make it a goal?
- 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.
It is far from clear to me that MASS should be a strict end-to-end mechanism.
- 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.
The issue is one of requirements. I can easily imagine getting pressure from
the security community to mandate use and checking of DNSSEC. If that happens
this effort is dead as the proverbial dodo, irrespective of anything else.
As others have noted, just getting DNS entries set up is problematic in some
cases. DNSSEC makes it much much harder.
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. The threat model needs to be explicit and what is out of bounds needs
to be clear. And everything that's secondary to our primary purpose needs to be
declared out of bounds.
- Facilitating offline validation
I don't see this as an issue. For one thing, most of the
existing formats allow for it. And for another, the present
day reality with SMTP makes accept-then-reject-later
approaches fairly problematic.
Can anyone provide some comments on how offline validation is a
distinguishing requirement?
Yes, someone please do.
Ned