ietf-mailsig
[Top] [All Lists]

RE: charter constraints list

2004-10-02 10:12:46

From: Dave Crocker
Sent: Saturday, October 02, 2004 10:35 AM

<...>

 -  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.

Yes, computational overhead is still quite important.  SSL is widely adopted
but used on only a small fraction of traffic that actually needs to be
secured.  The significant additional server overhead is the largest part of
the reason for this.  One could also argue that the cost of certs is an
issue, but this is determined by supply and demand.  If more people wanted
SSL certs, the cost would drop precipitously, just as we saw with domain
registrations.


<...>

 -  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?

I suggest that this does not belong in the charter.  John has stated that
the intention is to provide transit time coverage only, which is a very
helpful restriction when it comes to deployability.  Under this assumption,
which relaxes the constraints on the cryptography, offline validation would
be usable for a short time at best.  I think there is more downside to
having a user pull up a one-month old legitimate message and have it fail to
validate than allowing that user to assure validation for the first two
weeks or so.  Though any of the protocols under consideration can be made to
function offline, I can't think of any compelling reason why that should be
required, or even desirable.

--

Seth Goodman


<Prev in Thread] Current Thread [Next in Thread>