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?
- 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.
- 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.
- 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?
- 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.
- 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.
- 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?
Deployability is what matters. Period. A solution which
offers only a small increase in security (e.g., it can with
some trouble be sppofed, or replays are hard but possible, or
whatever) but which is deployable is going to be a million
times more valuable than any of the schems we've devised in
the past, even though those schems offer much much better
security.
The trick is going to be coming up with something that is
both deployable and which we can get approved. I'm honestly
not optimistic that there's an intersection between the two,
even at this late date and after so many failures.
I completely concur with Ned's concerns. And I concur that the
charter needs to have text that responds to the concerns directly
and well.
d/
--
Dave Crocker <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>