I'm surprised I can make a statement like "perhaps this group should not
be chartered" and get no reaction. So let me try a different approach
in this thread.
I agree with everything John Levine said. I would add that when you
don't explicitly have requirements it is important to have a clear
problem statement so that the goal is well understood.
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.
Perhaps it's just me again, but I don't find the distinguishing
characteristics listed in the charter compelling. Not to oversimplify,
but:
> Existing standardized mechanisms, for attaching a digital signature
> to an email message, are designed for different use than is required
> in this application. These distinctive requirements and
> characteristics may include:
> - 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.
> - 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.
> - 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.
> - Short term protection for purposes of transit
SSL/TLS has this one covered, I think.
> - DNS-based key-related queries
This is indeed a distinguishing feature, but there's the pesky DNSSEC
question...
> - 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.
> The working group will review and revise this list, in order to
> provide a clear statement of the engineering constraints and
> freedoms that apply to this work.
In the case of automated signing of messages, any SMTP client could
easily be enhanced to apply an existing secure email standard to every
outgoing message. I built one of these back circa 1990, when the email
standard of the day was Privacy Enhanced Mail (PEM). We did it at the
application later as proof of concept, as part of the MTA, but in
principle it could easily have been pushed down into the SMTP client.
We have offered a commercial solution capable of this for about a decade now. I
used to use it for all my Sun mail, as a matter of fact. But customer interest
in doing this has been low.
Keeping overhead down for high-volume email servers is problematic. As
soon as you add cryptography to a protocol it dominates the performance
characteristics. It's not clear to me what solution is going to
improve that. At high volume the usual solution is to add hardware
(CPUs, networking, encryption hardware) and I don't see that changing.
Agreed.
One potential area of overhead worth considering is the choice of where
the security parameters go and how they are represented. One could
argue that using S/MIME or PGP is weighty in the same way that using
HTML instead of text is weighty, but does anyone have any data on
whether the "weight" is in the cryptography or the message processing?
Putting the parameters in the SMTP transaction itself is probably a win.
Maybe, maybe not. It could be a mwans of addressing some issues. Or it could
end up being irrelevant.
Anonymity and short-term protection is all about choosing the identity
and the key sizes. You could apply the same requirements developed here
to any secure email protocol to achieve the goal. This is probably a
distinguishing goal.
I don't think anonymity is of sufficient interest that it distinguishes
much of anything.
Using the DNS to store the key could be used by any protocol. S/MIME
and PGP might need some tweaking (a profile) to get just the right
behavior for the lookup, but that's not much different than doing
something new.
Actually, I think this has the potential to be a clear distinguishing
characteristic. Keys in the DNS have the potential to significantly improve
deployability. However, if in the process we insist on DNSSEC protection for
such keys, I believe we basically end up back where we started. I see very
little uptake of DNSSEC and it isn't clear to me this is going to change in the
near future.
And clearly both S/MIME and PGP support offline validation. If there's
data from the SMTP transaction that's need then an MTA will have to
account for that, but I don't see that as a significant issue.
So what am I missing?
IMO what's missing from the charter is something that's really hard to add: The
major failing we have seen over and over and over again in this space is that
we've let the practically undeployable "best" be the mortal enemy of the very
deployable "just barely good enough".
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.
Ned
P.S. This message may come across as fairly harsh, but please keep in mind that
I speak as a coauthor of one of those failures, which I believed at the time to
be the One True Way, so in effect I'm being harsh with myself as much as anyone
else here.